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PATRIOT 


atriot,  our  cover  photo,  the 
cornerstone  of  the  U.S.  Army 
European  and  Contingency  Forces' 
integrated  air  defense  system,  has 
demonstrated  its  ability  to  counter 
the  tactical  ballistic  missile  threat  in 
battle. 


The  Patriot  missile  system  shown  in  the  desert  en- 
rimnment  at  White  Sands  Missile  Ihvuic,  X.M. , 
is  a  multipurpose  air  defense  system ,  dcsiytncd  to 
counter  nimaji,  oviv  missiles  and  tactical  ballistic 
missiles. 


Patriot  units  can  gain  Tactical 
Ballistic  Missile  (TBM)  engagement 
capability  without  retrofit  of  de¬ 
ployed  assets.  Patriot  Anti-Tactical 
Missile  (ATM)  capability  has  suc¬ 
cessfully  demonstrated  unparalled 
performance  in  its  engagements  pro¬ 
tecting  the  U.S.  and  Allied  troops  of 
Operation  Desert  Storm  as  well  as 
national  and  civilian  assets  in  Israel, 
Saudi  Arabia  and  Turkey. 


In  the  flight  test  program  before 
deployment,  Patriot  scored  15  for  15 
successes  against  real  and  surrogate 
TBM  targets. 

Patriot’s  operations  as  part  of 
Operation  Desert  Storm  demon¬ 
strated  a  performance  capability  that 
meets  or  exceeds  all  requirements, 
making  it  today  a  premier  air  defense 
system  in  the  Free  World. 


Vanifltt  l'hn<cd  /Inny  /Wnr 


In  test  programs,  Patriot  demon¬ 
strated  capability  to  counter  the  air¬ 
craft  threat  including  saturation 
raids,  high-speed  targets  and  highly 
maneuverable  targets  in  sophisticated 
electronic  counter  measures  (ECM) 
environments.  Patriot  fire  power,  in 
terms  of  rapid  rate  of  fire,  fast  reac¬ 
tion  time  and  multiple  simultaneous 
engagements  meets  or  exceeds  all 
specified  requirements. 

Patriot  system  effectiveness  against 
very  advanced  ECM  threats  and  the 
enhanced  system  survivability  result¬ 
ing  from  inherent  Patriot  mobility  are 


One  of  the  war's 
brightest  stars— 
Patriot— made  an 
impressive 
appearance  by 
intercepting  hayi 
missiles  headed  for 
Riyadh,  Ohahran 
and  1st  act. 


very  impressive.  Added  to  this  is  the 
demonstrated  system  availability  that 
exceeds  requirements  and  is  achieved 
by  a  combination  of  a  self-support 
concept  and  graceful  system  deg¬ 
radation. 

The  U.S.  Army  deployed  Patriot 
to  the  32nd  Air  Defense  Command  in 
Europe  and  the  11th  Air  Defense 
Brigade  in  the  United  States. 

The  32nd  is  integrated  into  the 
NATO  Air  Defense  force  structure 
and  the  11th  Air  Defense  Brigades 
assets  support  world  wide  contin¬ 


hi  mot  Air  Ikftwt  Spicm 


gency  operations  such  as  Operation 
Desert  Storm.  These  units  share  the 
air  defense  burden  with  Patriot  units 
of  our  Free  World  Allies. 

The  system  success  in  the  Middle 
East  and  on-going  national  studies  of 
air  defense  requirements  by  NATO 
and  other  Allied  nations  indicate  a 
high  interest  in  Patriot.  Both  the  cur¬ 
rent,  planned  and  potential  growth 
and  modernization  of  Patriot  should 
assure  that  it  remains  the  cornerstone 
for  The  Free  World's  tactical  air 
defenses. 

-  All  plum  t ounce/  ot  Ihubeon  Co 


Patriot  Anti-Tactual  Missile  capability  successfully  demonstrated  unpamlled  pcifaniuwce  pwteewuj  the  U.S.  and  Allied  troops  of  Operation  Desert  Storm.  In 
thejliciht  test  pivpram  before  deployment.  Patriot  scoied  15  for  15  successes  apainst  real  and  stimvjatc  Tactical  ballistic  Missile  targets. 
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Lhere  is  a  strong  premise  that 
effective  budget  control  re¬ 
quires  realistic  costing.  However, 
cost  analysis  and  estimation  is  not 
synonymous  with  cost  prediction  and 
forecasting.  Cost  results  from  scien¬ 
tific  and  social  phenonema  interac¬ 
tion  during  the  life  of  a  program. 
Therefore,  even  well-founded  and 
realistic  cost  estimates  may  contain 
serious  errors  because  improbable 
events  occurred  that  were  unknown 
and  unknowable  when  the  estimate 
was  made. 

Since  unforeseeable  events  will  oc¬ 
cur  that  will  raise  some  costs  for 
every  program,  a  strategy  must  be 
developed  for  controlling  costs  and 
keeping  within  the  approved  budget. 
Thus,  when  some  cost  elements  in¬ 
crease  unexpectedly,  other  costs  may 
be  reduced  to  mitigate  the  problem. 
The  absence  of  a  macro-strategy  for 
controlling  the  cost  of  weapon  sys¬ 
tems  inhibits  effective  program  man¬ 
agement.  The  core  of  such  a  strategy 
should  be  the  identification  of  "tar¬ 
gets  of  opportunity." 

Targets  of  opportunity  are  costs 
subject  to  control  by  an  effective  pro¬ 
gram  manager  (PM).  It  is  difficult  for 
a  PM  to  set  reasonable  cost-reduction 
objectives  because  many  cost  ele¬ 
ments  and  cost  drivers  are  not  sub¬ 
ject  to  PM  control.  But  the  con¬ 
trollable  elements  may  yield  substan¬ 
tial  dividends  if  managed  effectively. 


This  paper  considers  the  various 
causes  of  cost  growth  to  identify 
those  an  effective  program  manager 
could  influence.  Then,  life-cycle  cost, 
(LCC)  categories  are  presented  for  a 
hypothetical  aircraft  system1  to 
quantify  apporoximately  how  and 
where  program  management  might 
have  an  impact.  This  paper  seeks  to 
provide  a  foundation  for  identifying 
reasonable  targets  of  opportunity  for 
cost  reduction  over  the  life  of  a  pro¬ 
gram.  In  the  process  of  building  this 
foundation,  it  shows  some  of  the  pre-  , 
cepts  of  cost  analysis  to  be  a  hin¬ 
drance  in  understanding  where  lever¬ 
age  may  be  applied  to  reduce  costs. 

Conventional  Wisdom  and 
Rules  of  Thumb  As  Impediments 

Cost  analysts  sometimes  concoct 
rules  of  thumb  that  obfuscate  rather 
than  clarify  opportunities  for  cost 
reduction.  For  example,  it  is  often 
stated  that  most  life-cycle  costs  are 
committed  at  an  early  stage  of  de¬ 
velopment  and  that  operation  and 
support  dominates  life-cycle  cost. 
Furthermore,  even  well-researched 
findings  related  to  cost  growth  are 
sometimes  wrongly  construed  to  im¬ 
ply  that  cost  overruns  are  unavoid¬ 
able.  These  issues  are  discussed 
below. 

Figure  1  compares  the  cumulative  t1 
percentage  of  LCC  presumably  com-  ,  ■ 
mitted  at  each  program  milestone 
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Therefore,  even  a  marginally  com¬ 
petent  cost  analyst  could  estimate 
LCC  with  25  percent  accuracy  given 
a  minimal  description  of  a  prospec¬ 
tive  weapon  system.  A  description 
such  as  the  following  would  suffice: 
a  specified  quantity  of  a  single  engine 
fighter  aircraft  which  modestly  ad¬ 
vances  the  state  of  the  art  to  replace 
the  x  system  and  be  in  operation  for 
y  years. 

Another  artifact  of  conventional 
wisdom  is  that  operation  and  support 
accounts  for  75  percent  of  LCC.  This 
is  supposedly  irrespective  of  system 
type,  quanitity,  or  years  of  service. 
In  fact,  that  figure  seriously  over¬ 
states  the  magnitude  of  O&S  for  most 
systems.  Furthermore,  it  fails  to 
recognize  that  many  elements  of 
O&S  cost  result  from  allocations  of 
fixed  costs  associated  with  sustaining 
a  defense  force  and  have  little  to  do 
with  the  system  to  which  they  are 
assigned. 

Cost  growth  is  the  net  increased 
cost  to  the  government  for  items  or 
services  procured  or  to  be  procured. 
Cost  growth  has  been  carefully  mon¬ 
itored  over  time  for  major  DOD  pro¬ 


with  the  amount  actually  expended 
Thus,  for  example,  95  percent  of  LCC 
is  supposedly  determined  by  the  com¬ 
pletion  of  full-scale  development 
(FSD).  Yet,  only  16  percent  of  total 
funds  have  been  spent. 

While  this  may  be  true,  it  misses 
the  point.  No  system  really  begins 
with  a  zero  cost  baseline.  Instead, 
each  phase  of  its  life  cycle  will  require 
the  employment  of  certain  iden¬ 
tifiable  resources.  For  example,  an 
aircraft  will  need  engineering  and 
production  labor,  tooling,  raw 
materials,  subcontractor  and  vendor- 
supplied  components,  aircrews  and 
maintenance  personnel,  fuel,  etc.  The 
cost  of  those  resources  can  be 
estimated  with  various  degrees  of 
uncertainty  during  requirement 
definition,  and  refined  continually 
thereafter. 


grams.  Not  all 
cost  growth  is  preven¬ 
table  and  some  cost  growth,  even 
though  avoidable,  may  be  desirable. 
For  example,  technology  advances 
may  make  it  possible  to  incorporate 
modifications  that  result  in  an  overall 
increase  in  the  effectiveness  of  the 
system.  Such  cost  development  and 
production  is  not  always  predictable 
when  a  weapon  system  is  in  develop¬ 
ment  and  production  during  a  long 
period.  Historically,  economic  fac¬ 
tors  and  quantity  variances  have  ac- 

Dr.  Beltmmo  is  President  of  Beltramo 
and  Associates,  Los  Angeles,  a  manage¬ 
ment  consulting  firm  specializing  in  cost 
analysis  related  to  competitive  strategies, 
system  acquisition  policy  and  program 
management. 
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FIGURE  1.  FAULTY  CONVENTIONAL  WISDOM 
The  Impact  of  RDT&E  Decisions  on  LCC 


Milestones 

Boltramo  and  Aatoclates 


counted  for  about  three  quarters  of 
cost  growth.  A  program  manager 
cannot  directly  influence  either  of 
these  factors. 

All  issues  discussed  above  imply 
that  a  PM  cannot  have  an  important 
impact  on  cost.  However,  program 
managers  can  affect  cost  reduction. 
The  PM  must  first  assess  the  probable 
relative  and  absolute  magnitudes  of 
the  elements  of  life-cycle  cost.  Then, 
the  program  manager  must  define  ob¬ 
jectives  for  reducing  costs  for 
elements  identified  as  targets  of  op¬ 
portunity.  Those  issues  are  dealt  with 
below.  The  following  section 
discusses  where  a  program  manager 
can  make  a  difference.  This  contrasts 
with  conventional  wisdom  about 
most  cost  elements  being  beyond  a 
PM's  control. 

An  Assessment  of 
"Manageable  Cost  Elements" 

A  rough  estimate  of  LCC  for  a 
hypothetical  fighter  aircraft  system 
shows  which  cost  elements  PMs 
might  affect.  The  following  assump¬ 
tions  were  made  to  estimate  life-cycle 
costs  (exclusive  of  government  costs): 


—Alternative  procurement  quan¬ 
tities  of  140  and  400  aircraft 
—Alternative  operational  lives  of 
15  and  20  years 

—Procurement  costs  were 
estimated  by  applying  the  Beltramo 
and  Associates  Fighter  Aircraft  Cost 
Estimating  Model  to  hypothetical 
light  weight  fighter  subsystem 
weights 

—Munitions,  armament,  and  sup¬ 
port  equipment  were  not  included 
under  procurement 
—Initial  spares  were  estimated  as 
25  percent  of  flyaway  cost 
— O&S  costs  were  based  on  F-16 
squadrons  of  24  primary  alert  aircraft 
(PA A),  each  with  300  annual  flying 
hours.  They  were  estimated  using  the 
USAF  CORE  Model. 

The  estimates  are  presented  in 
Table  1.  The  estimates  provide  a 
rough  approximation  of  the  absolute 
and  relative  magnitudes  of  the 
various  LCC  elements.  They  lack 
much  of  the  detail  and  rigor  that 
would  be  desirable  for  other  pur¬ 
poses.  For  example,  RDT&E  and 
nonrecurring  costs  are  constant  for 
both  alternative  quantities.  However, 


in  reality  they  would  probably  be 
greater  for  400  units  due  to  additional 
facilitization  and  tooling  required  to 
support  a  higher  production  rate. 

Table  1  shows  that  acquisition 
(i.e.,  RDT&E,  nonrecurring,  and  pro¬ 
curement)  costs  tend  to  dominate  for 
low  quantities  and  shorter  periods  of 
operation  while  O&S  costs  tend  to 
dominate  far  higher  quantities  and 
longer  periods  of  operation.  This  is 
logical  as  O&S  costs  would  be  negli¬ 
gible  for  a  system  that  is  never  de¬ 
ployed  and  relative  acquisition  costs 
would  be  minimized  for  a  system 
with  and  extremely  long  life.  Conse¬ 
quently,  operational  plans  should 
drive  a  PM's  cost  reduction  strategy . 
If  O&S  costs  are  low  even  under 
worst  case  asumptions,  an  added  in¬ 
vestment  to  reduce  them  further  may 
not  pay  off.  The  remainder  of  this 
paper  considers  costs  which  might  be 
directly  affected  by  the  PM  as  well  as 
the  magnitude  of  the  impact  he  could 
make. 

Actions  taken  by  a  program 
manager  could  affect  from  85.6  to 
91.2  percent  of  LCC  for  the  cases 
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TABLE  1.  LIFE-CYCLE  COST  COMPARISON  OF  LIGHT  WEIGHT  FIGHTER 
AIRCRAFT  ALTERNATIVES 


140  Aircraft  400  Aircraft 


15  Yr. 

Life 

20  Yr. 

"Life 

15  Yr. 

Life 

20  Yr. 

'Life 

S 

% 

S 

% 

$ 

%' 

$ 

% 

RDT&E  and  Nonrecurring 

1,796 

324% 

1,796 

29.0% 

1,796 

15.5% 

1,796 

13.2% 

Procurement 

•  325% : 

,  295% 

4#>0 

295% 

Airframe 

952 

17.2% 

952 

15.4% 

2040 

17.5% 

2040 

15.0% 

Engines 

252 

4.5% 

252 

4.1% 

600 

5.2% 

600 

4.4% 

Avionics 

238 

4.3% 

238 

3.8% 

560 

4.8% 

560 

4.1% 

Initial  Spares 

360 

6.5% 

360 

5.8% 

800 

6.9% 

800 

5.9% 

Operations  and  Support 

1,942 

35;t% 

Tim 

•';:41i9%v::- 

5328 

■-mm 

■  2772 

Unit  Mission  Personnel 

' 

r-ijm:- 

13.9% 

2155 

,35,9%; 

Aircrew 

62 

1.1% 

83 

1.3% 

187 

1.6% 

249 

1.8% 

Aircraft  Maintenance 

394 

7.1% 

525 

8.5% 

1,181 

10.2% 

1,575 

11.6% 

Other 

83 

1.5% 

no 

1.8% 

248 

21% 

331 

24% 

Unit  Level  Consumption 

385 

6.9% 

W* 

■  •  m, 

L539-'- 

POL 

272 

4.9% 

362 

5.8% 

815 

7.0% 

1,087 

8.0% 

AC  Maint  Material 

113 

20% 

151 

24% 

339 

29% 

452 

3.3% 

Depot  Maintenance 

356 

6.4% 

475 

7.7% 

1,069 

9.2% 

1,425 

10.5% 

Sustaining  Investment 

238 

4.3% 

338 

■  m%\: 

6,i%: 

952 

%:;im 

Rep  Spares 

183 

3.3% 

244 

3.9% 

549 

4.7% 

732 

5.4% 

Support  Equipment 

48 

0.9% 

65 

1.1% 

145 

1.2% 

194 

1.4% 

Modification  Kits 

7 

0.1% 

9 

0.1% 

20 

0.2% 

26 

0.2% 

Installation  Support  Pets 

91 

L6% 

122 

20%  ' 

'  /...:274.;- 

24% ; 

■  ;365>: 

27% 

Base  Opr  Support 

74 

1.3% 

99 

1.6% 

223 

1.9% 

298 

22% 

Real  Prop  Maint 

10 

0.2% 

13 

0.2% 

29 

0.2% 

38 

0.3% 

Medical 

7 

0.1% 

10 

0.2% 

22 

0.2% 

29 

0.2% 

Indirect  Pen  Support 

77 

14% 

103: 

■ 

■  232 

20% 

310 

23%. 

Misc  O&M  Support 

45 

0.8% 

60 

1.0% 

136 

1.2% 

181 

1.3% 

Medical  Support 

9 

0.2% 

12 

0.2% 

27 

0.2% 

37 

0.3% 

PCS 

23 

0.4% 

31 

0.5% 

69 

0.6% 

92 

0.7% 

PenAcqandTmg 

256 

4 m 

•342; 

.5,5% 

769 

6.6% 

1,026 

7.6% 

Acq  (Inc.  Basic  Tng) 

198 

3.6% 

265 

4.3% 

595 

5.1% 

794 

5.9% 

Specialty  Training 

58 

1.0% 

77 

1.2% 

174 

1.5% 

232 

1.7% 

Total  LCC 

5,540 

ioao% 

6,189 

ioao% 

$624 

i0o;o% 

$568 

iod;o% 

shown  in  Table  1.  Specifically,  a  PM  while  poor  strategies  could  increase  ation  and  support.  Therefore,  the 
could  affect  all  cost  elements  except  costs.  Each  LCC  category  and  some  motivation  of  PMs  during  this  phase 
O&S  costs  related  to  aircrews,  in-  key  cost  elements  are  considered  should  be  to  make  wise  tradeoffs, 
stallation  support  personnel,  indirect  below  to  indicate  the  potential  impact  This  might  result  in  higher  short-term 
personnel  support,  and  personnel  ac-  of  an  effective  PM.  costs  to  achieve  long-term  saving, 

quisition  and  training.  Although  nrv_.,  _  ,  ..  .  ~  , 

none  of  the  affected  costs  could  be  RD1&E  and  Nonrecurring  Costs  The  Rpy^.g  costs  are  perhaps 
eliminated,  they  might  be  leduced  Funds  for  RDT&E  and  nonrecur-  more  subject  to  program  manager 
somewhat.  Of  course,  better  deci-  ring  investments  can  provide  a  good  control  than  any  other  LCC  category, 
sions  could  lead  to  more  savings  return  during  procurement  and  oper-  This  is  because  planned  performance 
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specifications,  operational  capabili¬ 
ties  and  maintenance  objectives  may 
be  reduced  to  stay  within  budget. 
Also  the  number  of  prototype  aircraft 
can  be  reduced  and  testing  can  be 
limited  to  minimize  costs. 

It  would  be  difficult  to  prove  a 
high  correlation  between  cost  and  op¬ 
erational  capabilities  and  reliability 
and  maintainability.  But  "-ility"  im¬ 
provements  are  rarely  obtained  for 
free.  Therefore,  program  manage¬ 
ment  should  attempt  to  get  the  most 
from  available  RDT&E  funds  and  not 
attempt  to  achieve  false  savings  by 
cutting  corners. 

The  division  between  nonrecurring 
investment  and  RDT&E  i  ..omewhat 
arbitary  because  both  categories  in¬ 
clude  one-time  costs  incurred  in  prep¬ 
aration  for  production.  The  magni¬ 
tude  of  the  nonrecurring  investment 
depends  chiefly  on  the  aircraft  design, 
number  of  prototypes,  length  and 
complexity  of  the  testing  program, 
and  tooling  for  the  target  production 
rate. 

Like  RDT&E,  nonrecurring  invest¬ 
ment  may  also  represent  short-term 
costs  to  achieve  greater  long-term 
savings  (e.g.,  more  costly  tooling 
may  permit  beneficial  capital/labor 
tradeoffs).  Thus,  the  program 
manager  should  exempt  much  of  13 
to  32  percent  of  ICC,  represented  by 
the  RDT&E  and  nonrecurring  invest¬ 
ment  categories  Table  1,  from  cost¬ 
cutting  efforts.  The  PM  should  in¬ 
stead  concentrate  on  maximizing  the 
value  obtain  from  available 
resources. 


Procurement 

Aircraft  procurement  accounts  for 
about  29  to  34  percent  of  LCC  in  the 
examples  shown  in  Table  1.  This 
should  be  minimized  within  the  con¬ 
straint  of  obtaining  an  aircraft  that 
meets  design  specifications  and 
operational  requirements.  Of  course, 
the  potential  for  cost  reduction 
depends  upon  the  accuracy  and  basis 
of  the  estimate  incorporated  into  the 
budget.  For  example,  a  parametric 
cost  estimate  for  an  advanced 
technology  airframe  prepared  using 
models  based  upon  conventional  air¬ 
frame  technologies  might  offer 
greater  room  for  reduction  than 
engineering  cost  build-up  based  upon 

Program  Manager 


well-known  components  and 
processes. 

Program  managers  may  implement 
policies  that  encourage  and  enable 
the  contractor  to  be  a  more  efficient 
producer.  For  example,  the  PM  may 
act  to  assure  an  efficient  production 
rate  to  avoid  excess  capacity  and 
associated  higher  overhead  costs. 
Multiyear  contracting  may  be  im¬ 
plemented  when  there  is  no  risk  of 
program  cancellation  and  when  a 
long-term  commitment  will  result  in 
lower  costs.  These  result  from  taking 
advantage  of  volume  purchases  and 
avoiding  production  interruptions. 
Also,  the  judicious  implementation  of 
engineering  changes  during  produc¬ 
tion  can  reduce  costs. 

Since  the  reduction  of  procurement 
costs  is  sensitive  to  the  estimating 
methodology  upon  which  the  budget 
is  derived,  quanitfying  the  potential 
for  cost  reduction  is  highly 
speculative.  However,  extensive  data 
on  competitive  programs  indicate 
that  price  can  often  be  reduced 
significantly.  Therefore,  20  percent 
reduction  of  procurement  costs  may 
be  a  reasonable  goal.  That  would 
reduce  LCC  by  about  6  to  8  percent . 
Of  course,  the  uncertainty  for  achiev¬ 
ing  this  savings  would  be  moderate 
to  high. 
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Operation  and  Support 

The  PM  might  affect  the  logistics 
support  cost  (LSC)  component  of 
O&S.3  Elements  of  LSC  represent 
about  26  to  43  percent  of  LCC  in  the 
examples  provided  in  Table  1.  The 
LSC  is  driven  by  reliability  and  main¬ 
tainability.  For  example,  the  program 
manager  can  affect  R&M  by  contract 
incentives  and  warranty  provisions. 

Newer  aircraft  exhibit  substantially 
reduced  maintenance  man  hours 
compared  to  aircraft  from  the 
previous  generation.  For  example, 
USAF  logistics  support  cost  factors 
indicate  that  the  annual  cost  for  an 
F-16  squadron  is  about  30  percent 
lower  than  for  an  F-4E  squadron. 
Hence,  an  LSC  savings  of  as  much  as 
25  percent  compared  with  current 
fighter  aircraft  might  be  a  reasonable 
goal  for  a  PM.  That  would  reduce 
LCC  by  about  6  to  10  percent. 

Conclusion 

A  preoccupation  with  uncon¬ 
trollable  cost  elements  and  factors 
which  cause  cost  growth  and  mis¬ 
guided  conventional  wisdom  have 
averted  attention  from  real  cost 
reduction  opportunities.  Lower  costs 
may  be  achieved  if  targets  of  oppor¬ 
tunity  are  identified  and  pursued  at 
an  early  stage  in  a  program.  An  ef¬ 
fective  program  manager  can  have  an 
important  impact  on  reducing  pro¬ 
gram  cost.  Potential  cost  savings  for 
the  light-weight  fighter  example  are 
summarized  in  Table  2  by  LCC  cate¬ 
gory.  They  were  derived  by  applying 
the  gross  assumptions  discussed 
above  to  the  cost  estimates  presented 
in  Table  1.  A  program  manager  may 
affect  cost  elements  equal  to  between 
86  to  91  percent  of  life-cycle  cost  in 
this  example.  An  LCC  reduction  of 
nearly  17  percent  represents  a  signifi¬ 
cant  potential  savings  and  may  not 
be  an  unreasonable  goal. 

Although  it  is  impossible  to 
measure  the  actual  effect  of  a  PM  on 
cost,  there  is  little  doubt  that  it  can 
be  considerable.  This  paper  examined 
how  an  effective  program  manager 
can  reduce  cost.  Conversely,  poor 
program  management  decisions  can 
increase  cost,  reduce  performance 
and  delay  schedules.  Therefore,  it  is 
crucial  to  adopt  strategies  that  will 
lower  LCC  as  well  as  strategies  for 
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140  Aircraft  400  Aircraft 


15  Yr.  Life 

20  Yr.  Life 

15  Yr.  Life 

20  Yr.  Life 

% 

Est 

Pot 

Est 

Pot 

Est 

Pot 

Est 

Pot 

Sav. 

_  Cost 

Sav. 

Cost 

Sav. 

Cost 

Sav. 

Cost 

Sav. 

RDT&E  and  Nonrecurring 

0 

1,796 

0 

1,796 

0 

1,796 

0 

1,796 

0 

Procurement 

20 

1,802 

360 

1,802  360 

4,000 

800 

4,000 

800 

Operations  &  Support 

LSC 

25 

1,456 

364 

1,941 

485 

4,366 

1,092 

5,822 

1,456 

Ops.  &  Ind.  Supt 

NA 

486 

0 

650 

0 

1,462 

0 

1,950 

0 

Total  LCC 

5,540 

6,189 

11,624 

13,568 

Total  PM  Cost  Impact 

5,054 

5,539 

10,162 

11,618 

Potential  PM  Savings 

724 

846 

1,892 

2,256 

PM  Impact/LCC 

91.2% 

89.5% 

87.4% 

85.6% 

Potential  Savings 

13.1% 

13.7% 

16.3% 

16.6% 

meeting  technical,  performance  and  Endnotes  offers  no  calculations  to  support  its 

schedule  goals.  L  Costs  shown  in  the  tables  were  assertions  but,  instead,  an  editor  of 

The  uncertainties  inherent  in  even  prepared  for  an  analysis  completed  in  Publication  no  e  a  percen- 

the  best  cost  analyses  can  lead  to  the  early  1980s.  Therefore,  the  ab-  fa8“  shown  rePresent  exPert  °Pin- 
budget  overruns.  Higher  costs  in  solute  amounts  are  no  longer  valid  Ion> 

some  areas  may  be  offset  somewhat  and  even  relative  amounts  may  have  3.  These  include  all  O&S  elements 
by  identifying  cost  elements  and  cost  changed.  But  they  are  still  useful  for  except  aircrews,  installation  support 
drivers  that  may  be  responsive  to  the  intended  purpose.  personnel,  indirect  personnel  sup- 

program  management  initiatives  and  port,  and  personnel  acquisition  and 

implementing  strategies  for  control!-  2.  A  source  for  this  figure  is  the  training, 
ing  them.  Navy  Program  Manager's  Guide.  It 
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STANDARDIZATION 


THE  “HITHER  AND  YAWN 
(YON)”  OF  STATEMENT  OF 
WORK  PREPARATION 

A  Trip  Through  the  Process 
With  the  Fictitious  B-3 


As  you  may  remember,  our 
first  article  on  statements  of 
work  (SOW)  appeared  in  the  May- 
June  1990  issue  of  this  journal.  It  was 
entitled  "Is  Your  SOW  a  Statement 
of  Work  or  a  Source  of  Woe?”  and' 
was  aimed  at  educating  you  on  the 
purpose  of  a  SOW,  history  of  SOW 
preparation  guidance,  mechanics  and 
basic  results  of  a  SOW  Survey  of 
more  than  2,200  Air  Force  System 
Command  (AFSC)  program  manag¬ 
ers,  interrelationship  of  the  SOW  to 
the  solicitation,  and  the  SOW  review 
process. 

We  have  received  numerous  calls, 
letters,  and  face-to-face  comments  on 
the  timeliness  of  the  article.  The  most 
widely  asked  question  has  been:  "When 
will  the  follow-up  article  be  available, 
as  advertised?"  Here  it  is. 

After  restating  the  problem,  we’ll 
explain  the  format,  purpose  and  con¬ 
tent  of  the  three  major  SOW  sections, 
identify  and  describe  the  five  types  of 
SOWs,  review  do’s  and  don’ts  of  SOW 
preparation,  highlight  sources  of 


Mr.  Andrews  is  an  assistant  professor 
of  acquisition  logistics,  School  of  Systems 
and  Logistics,  Air  Force  Institute  of 
Technology,  Wright-Patterson  AFB, 
Ohio. 

Captain  Adler  is  the  SRAM  II 
Warhead  integration  program  manager, 
SRAM  II System  Program  Office,  Aeiv- 
nautical  Systems  Division ,  Wright- 
Patterson  Apr,  Ohio. 


Mr.  Richard  A.  Andrews 
Captain  R,  Terry  Adler ,  USAF 


SOW  education  or  training,  and  con¬ 
clude  with  recommendations  for  im¬ 
proving  the  SOW  development  pro¬ 
cess.  Our  sources  have  been,  and  will 
continue  to  be,  MIL-HDBK-245B,  our 
program  manager  survey,  govern¬ 
ment  policies,  our  own  experiences, 
logic,  and  common  sense. 


We  realize  that  it's 
one  thing  to 
prepare  a  guidance 
document  and 
quite  another  to 
apply  it. 


can  be  found  in  an  August  1980  let¬ 
ter  from  the  Office  of  the  Under 
Secretary  of  Defense  which  said  in 
part: 

Problems  exist  with  SOWs  as 
presently  written.  They  have 
become  overly  complex,  lack 
clarity  and  vary  in  content.  Dif¬ 
ferent  services  use  different 
guidance  documents  for  their 
preparation.  As  a  result,  these 
problems  are  magnified  in  in¬ 
dustrial  facilities  that  have  con¬ 
tracts  with  more  than  one  buy¬ 
ing  command.  There  is  a 
need  for  clear,  uniform 
guidance  in 
preparing 
SOWs. 


Restatement  of  Problem 

Perhaps  the  most  point-blank 
statement  of  the  problem  we  face  in 
SOW  development,  and  the  resultant 
compelling  need  for  improvement. 


This  letter,  written  more  than  10 
years  ago,  chartered  the  formation  of 
an  ad  hoc  group  whose  objectives 
were  to  "...develop  a  military  stan¬ 
dard  or  handbook  which:  provides  ?. 
broader  base  of  proposers  resulting 
from  complete,  clear  requirements 
and  risk  identification;  reduces  delays 
in  source  selection  by  reducing  or 
eliminating  the  need  to  go  back  to 
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proposers  for  additional  information 
on  qualification,  etc;  minimizes  the 
contractors  building  in  contingency 
allowances  resulting  from  unclear  re¬ 
quirements;  enhances  the  quality  and 
inventiveness  of  proposals;  reduces 
proposal  size,  cost,  and  preparation 
time  by  the  government," 

From  what  we  can  determine,  the 
result  of  the  committee  was  MIL- 
HDBK-245B.  Unfortunately,  as  a 
handbook,  it  only  serves  as  "guid¬ 
ance"  just  as  the  original  letter  op¬ 
tionally  tasked  the  committee  to 
develop.  The  overwhelming  interpre¬ 
tation  of  the  term  "guidance  docu¬ 
ment"  has  been  taken  to  mean  that 
compliance  is  not  mandatory.  Con¬ 
sequently,  what  appears  to  have 
resulted  during  the  years  are  SOWs 
with  an  infinite  variety  of  formats 
and  contents  almost  as  numerous  as. 
there  are  acquisition  organizations. 


policy  is  contained  in  AFSCR 
800-6...."  That  was  in  error.  It  should 
have  said  "Air  Force  Systems  Com¬ 
mand  SOW  preparation  policy  is 
contained  in  AFSCR  800-6.”  The  dif¬ 
ference  is  significant.  In  the  former, 
the  entire  Air  Force  would  have  been 
required  to  comply  with  the  MIL- 
HDBK-245B  procedures,  while  in  the 
latter,  only  Air  Force  Systems  Com¬ 
mand  organizations  would  be  ac¬ 
countable.  Subsequently,  we  have 
discovered  that  our  mistake  has  been 
rendered  academic.  The  AFSCR 
800-6  has  been  rescinded.  What  we 
saw  as  a  first  real  step  toward  true 
SOW  standardization  has  been 


■ 
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As  trivial  as  it  may  sound,  the  word 
"implement"  was  never  used  in  the 
OSD  letter.  We  realize  that  it's  one 
thing  to  prepare  a  guidance  document 
and  quite  another  to  apply  it.  Our  ex¬ 
periences  in  academia  have  shown 
that  a  surprisingly  large  percentage  of 
acquisition  personnel  are  not  aware 
that  MIL-HDBK-245B  exists,  let 
alone  do  they  use  it  in  SOW  prep¬ 
aration. 

Before  we  progress  too  far,  one 
correction  must  be  made.  In  our 
previous  article  we  stated  that  "Cur¬ 
rent  Air  Force  SOW  preparation 


A  futmal  s»im%  the  B-X 

voided.  It  now  appears  we  may  have 
reverted  back  to  where  we  started, 
with  guidance  only.  We  must  con¬ 
clude  that  as  long  as  there  is  no  stan¬ 
dardized  requirement  for  SOW  prep¬ 
aration,  we  will  continue  to  prepare 
and  issue  SOWs  that  are  "...overly 
complex,  lack  clarity  and  vary  in 
content." 

SOW  Format 

In  addition  to  a  title  page,  the  basic 
SOW  should  consist  of  three  sections: 
Scope,  Applicable  Documents,  and 
Requirements.  If  the  SOW  is  more 
than  five  pages  in  length  it  should 
have  a  table  of  contents.  Deviation 
from  the  standard  format  may  be 
made  to  accommodate  overriding 
program  needs. 


Section  1:  Scope 

This  SOW  section  contains  a  de¬ 
scription  of  what  the  SOW  covers; 
i.e,,  section  1  in  a  full-scale  develop¬ 
ment  SOW  would  specify  that  this 
SOW  is  for  the  design,  development 
and  testing  of  the  system.  Where  ap¬ 
propriate,  it  should  include  a  sum¬ 
mary  background  of  the  problem 
and,  depending  on  SOW  type,  a  sys¬ 
tem  description.  Separate  levels  of  in¬ 
denture  in  this  section  may  be 
necessary  to  support  complex  ac¬ 
quisitions,  especially  for  background 
information.  Tasking  the  contractor 
to  perform  work,  or  the  discussion  of 
data  requirements,  or  data  deliver¬ 
able  products  should  never  be  in¬ 
cluded  in  this  section. 

Section  2:  Applicable  Documents 

Section  2  is  used  to  list  all  ap¬ 
plicable  documents  called  out  by 
specific  reference  in  section  3  of  the 
SOW.  The  actual  extent  of  applica¬ 
bility  of  a  document  referenced  in 
section  2  will  be  specified  in  section 
3  by  identifying  only  those  portions 
of  the  document  needed  to  solicit  the 
effort  required.  The  referenced  docu¬ 
ment  must  be  identified  by  number 
and  title  and  it  would  be  beneficial  to 
include  the  date  of  the  publication. 
The  listing  of  an  applicable  document 
in  section  2  without  having  it  specif¬ 
ically  mentioned  in  section  3  does  not 
create  an  impacting  condition  on  the 
contractor.  Never  use  DOD  and  de¬ 
partmental  instructions  (government 
regulations  and  manuals)  in  a  SOW, 
except  in  Type  V  SOWs.  They  were 
devised  to  manage  and  control  gov¬ 
ernment  in-house  activities,  not  a 
contractor.  Only  contractually  ap¬ 
plicable  tailored  standards,  specifica¬ 
tions  and  so  forth  should  be  used  in 
a  SOW.  Guidance  documents  may  be 
conveyed  to  the  contractor  in  the  In¬ 
structions  to  Offeror/ Bidder  (section 
L)  of  the  solicitation. 

Section  3:  Requirements 

This  is  the  critical  section  of  the 
SOW.  Here  is  where  we  define  the 

EDITOR'S  NOTE: 

Because  of  a  resounding  response 
to  their  first  article  in  the  May-] line 
1990  Program  Manager,  the  authors 
have  written  more  on  SOW 
development. 
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work  or  task  efforts  to  be  performed 
by  the  contractor.  The  arrangement 
of  section  3  must  be  systematic,  log¬ 
ical  and  in  accordance  with  the  work- 
breakdown  structure  specified  in 
M1L-STD-881.  It  is  vita!  that  each 
contractor  tasking  contain  the  proper 
reference  to  "shall,"  "should"  or 
"may"  to  indicate  clearly  whether  a 
tasking  is  "mandatory,"  "desirable," 
or  "alternative."  The  term  "will"  may 
be  used  to  express  a  declaration  of 
purpose  or  futurity;  i.e,,  common 
support  equipment  for  in-factory  use 
will  be  provided  to  the  contractor  as 
government  furnished  equipment. 
Where  practical,  taskings  should  be 
written  in  a  chronological  order  and 
in  a  manner  and  sequence  to  facilitate 
administration  of  the  contract. 

Types  of  Sows 

According  to  M1L-HDBK-245B 
there  are  five  types  of  SOWs.  They 
are  Concept  Exploration,  Demonstra¬ 
tion  and  Validation,  Full-Scale 
Development,  Production  and  De¬ 
ployment,  and  Nonpersonal  Services. 
Though  the  names  of  the  phases  in 
the  acquisition  process  may  change, 
the  fundamental  activities  that  occur 
in  a  given  phase  remain  fairly  con¬ 
stant.  Although  the  SOW  is  primarily 
viewed  as  a  document  that  defines  a 
contractor's  responsibilities,  the 
SOW  preparation  procedures  should 
be  applied  independent  of  who  will 
perform  the  effort,  even  if  that  work 
is  done  by  another  government 
organization. 

TYPE  I: 

Concept  Exploration  (CE) 

The  objective  of  the  CE  phase  is  to 
define  and  identify  alternative  system 
design  concepts  that  may  satisfy  mis¬ 
sion  needs.  Because  of  our  limited 
ability  to  accurately  identify  and 
define  the  product  desired,  a  Type  I 
SOW  is  usually  restricted  to  an  ex¬ 
pression  of  objections  or  goals.  A 
Type  I  is  used  when  it  is  necessary  to 
define  the  technical  requirements  in 
the  SOW  because  the  efforts  are  in¬ 
evitably  stated  in  terms  of  objectives 
or  goals  rather  than  quantitative  or 
qualitative  tasks;  like  those  included 
in  a  specification.  In  fact,  typical  pro¬ 
grams  do  not  have  a  system  specifica¬ 
tion  at  this  point  in  the  acquisition 
cycle.  For  this  reason,  you  will  likely 
see  specification  like  requirements  in 


the  concept  exploration  SOW.  Like¬ 
wise,  data  or  technical  reports  result¬ 
ing  from  the  work  tasks  defined  in  a 
Type  I  are  discussed  and  ordered 
within  the  SOW.  The  AFR  310-1, 
Management  of  Contractor  Data, 
specifically  states  that  provisions  of 
the  regulation  do  not  apply  to 
"Research  or  development  contracts 
when  reports  are  the  only  deliverable 
item  under  the  contract."  Therefore, 
a  separate  contract  data  requirement 
list  (CDRL)  normally  would  not  be 
required  on  a  CE  contract. 

Section  1  of  a  Type  1  SOW  rou¬ 
tinely  will  contain  a  statement  of  the 
problem,  a  short  functional  de¬ 
scription  of  the  overall  system,  and 
a  graphic  display  of  major  milestones 
of  the  program  in  time  sequence.  Sec¬ 
tion  3  generally  will  provide  a  sum¬ 
mation  of  known  alternatives  for 
development;  a  time  phasing  of 
studies,  if  appropriate;  data  reporting 
requirements;  and,  where  necessary, 
an  identification  of  subsystem  rela¬ 
tionships,  We  must  be  cautious  that 
we  do  not  write  a  CE  SOW  where  the 
description  of  the  work  effort  is  so 
vague  that  it  renders  the  contract  dif¬ 
ficult  to  enforce  or  where  it  is  so 
stringent  that  it  stifles  contractor  flex¬ 
ibility  and  innovativeness. 

TYPE  II; 

Demonstration  and 
Validation  (D&V) 

A  Type  II  SOW  will  be  more 
descriptive  of  contractor  work  efforts 
and  more  conclusive  in  identifying 
goals  and  objectives.  It  is  used  to 
refine  and  define  to  a  lower  level  the 
details  of  system  performance  and 
support.  Essentially,  the  D&V  phase 
SOW  is  limited  in  scope  to  efforts  re¬ 
quired  to  conduct  the  proofing  or 
prototyping  (if  deemed  appropriate), 
assess  results  of  proofing  or  prototyp¬ 
ing,  and  define  system  performance 
requirements  to  the  end-item  level. 
Work  efforts  in  a  Type  II  SOW 
would  include  system  engineering, 
possible  construction  of  hardware, 
analysis  of  design  and  cost  trade-offs, 
risk  assessment  and  program  plan¬ 
ning.  To  ease  transition  into  the  full- 
scale  development  phase  (FSD),  the 
D&V  SOW  should  be  correlated  to 
selected  elements  of  the  FSD  prelim¬ 
inary  work  breakdown  structure 
elements  that  are  applicable. 


Normally,  a  D&V  contract  will  re¬ 
quire  delivery  of  defense  material,  so 
it  is  necessary  that  a  separate  CDRL 
for  data  ordering  be  used.  Per  AFR 
310-1,  the  SOW  still  must  stipulate 
the  work  effort  that  would  generate 
the  by-product  of  data.  However,  the 
SOW  does  not  directly  call  out  the 
preparation  or  delivery  of  the  data, 
except  in  a  Type  I  SOW.  The  re¬ 
sulting  data  by-products  from  a 
typical  Type  II  SOW  would  generally 
include  systems  engineering  and  pro¬ 
gram  management  plans,  develop¬ 
ment  specifications,  logistics  support 
analysis  record,  engineering  drawings 
(level  1  or  equivalent),  cost  reports, 
etc. 


TYPE  III: 

Full-Scale 

Development  (FSD) 

A  Type  III  SOW  is  prepared  when 
a  specification  is  used  to  define  the 
qualitative  and  quantitative  technical 
requirements  for  performance  and 
support.  During  this  phase,  the  con¬ 
tractor  performs  design,  develop¬ 
ment,  test  and  evaluation  of  the 
system  based  on  the  functional  and 
allocated  baselines  that  are  products 
of  the  system  definition  in  the  con¬ 
cept  exploration  and  demonstration 
and  validation  phases.  The  system  in¬ 
cludes  the  prime  mission  defense 
material  and  all  items  necessary  for 
its  support.  Some  additional  SOW 
taskings  would  include  a  continua¬ 
tion  of  design  and  cost  trade-offs, 
design  and  management  reviews,  risk 
assessment,  and  the  LSA  process;  im¬ 
plementation  of  quality  and  config¬ 
uration  management  programs;  plan¬ 
ning  of  test  support;  and  production 
planning.  The  intended  output  of  the 
FSD  phase  is  a  configured  system  and 
the  documentation  needed  to  produce 
that  system. 

When  management  data  are  ex¬ 
pected  to  result  from  a  task,  the 
description  of  the  work  effort  should 
be  detailed  enough  to  result  in 
generating  the  desired  information 
without  having  to  rely  on  the  data 
item  description  as  the  forcing  func¬ 
tion  for  data  creation.  The  pro¬ 
cedures  for  FSD  data  identification 
and  contractual  acquisition  are  ac¬ 
complished  in  the  same  manner  as 
was  specified  for  the  D&V  phase. 
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TYPE  IV: 

Production  and 
Deployment 

The  Type  IV  SOW  is  used  to 
culminate  end-efforts  of  the  research 
and  development  phases  by  suppor¬ 
ting  production  and  ultimate  deploy¬ 
ment  of  the  system.  In  this  phase,  the 
contract  specification  is  converted 
into  a  military  specification  to  con¬ 
trol  the  "manufacture  to"  design  and 
the  manufacturing  processes.  All 
necessary  tasks  deferred  from  earlier 
phases  will  be  readdressed  and  ac¬ 
tions  initiated  for  their  completion. 
In  a  large  percentage  of  cases,  these 
deferrals  involve  support  resources: 
such  as,  provisioning,  technical 
publications,  support  equipment  and 
training.  Most  support  deferrals  to 
the  production  phase  are  usually,  but 
not  exclusively,  limited  to  depot-level 
capabilities.  Many  taskings  included 
in  the  production  SOW  are  logical 
and  necessary  continuations  of  efforts 
begun  in  the  FSD  phases  or  earlier. 
Data  identification  and  acquisition 
process  in  the  production  phase  are 
done  in  the  same  manner  used  in  the 
D&V  and  FSD  phases. 

TYPE  V: 

Nonpersonal  Services 
(NPS) 

The  Type  V  SOW  is  used  when  the 
need  for  contractor  support  is  iden¬ 
tified  independent  of  the  actual 
development  and  procurement  of  the 
defense  material  item.  The  NPS  con¬ 
tracts  can  occur  during  any  phase  of 
the  acquisition  cycle.  There  are  two 
criteria  that  must  be  satisfied  and 
adhered  to  when  contemplating  their 
use.  First,  the  SOW  must  explicitly 
establish  what  work  is  to  be  done  and 
require  the  delivery  of  a  product 
other  than  periodic  progress  reports. 
Second,  the  contractor's  employees 
must  not  be  supervised  by  the  gov¬ 
ernment  during  execution  of  the  work 
and  production  of  the  product. 

Unlike  previous  SOWs,  Type  I 
through  IV,  departmental  instruc¬ 
tions  and  other  policy  documents 
may  be  referenced  or  invoked  in  the 
SOW  to  define  to  an  NPS  contractor 
a  method  of  work  performance.  De¬ 
partmental  policies  and  procedures 
used  to  control  similar  in-house  work 
efforts  must  be  thoroughly  under¬ 
stood  by  the  SOW  writer  and  those 


rules  defined  for  the  contractor's 
guidance. 

Progress  reports  are  not  considered 
the  deliverable  product  in  an  NPS 
contract.  They  are  a  normal  part  of 
the  contract  management  process. 
When  used,  the  SOW  should  specify 
the  format  and  arrangement  of  the 
reports  to  include  work  accom¬ 
plished,  problems  encountered,  prob¬ 
lems  solved,  cost  information,  funds 
expended  and  frequency  of  report 
delivery.  A  CDRL  may  be  used  for 
ordering  other  data  items  as  needed. 

The  Do's  and  Don'ts 
Of  SOW  Preparation 

Perhaps  the  single  most  important 
factor  in  SOW  preparation  activities 
is  keeping  to  a  systems  engineering 
approach  in  organizing,  developing 
and  writing  individual  work  state¬ 
ments.  Remember,  the  SOW  is  the 
tasking  document  used: 

—By  the  government  to  delineate 
program  requirements  and  to  inte¬ 
grate  these  requirements  into  a  single¬ 
source  document. 

—By  the  contractor  to  price  out  the 
scope  of  the  effort,  set  objectives, 
agree  to  provide  work  as  stated  in  the 
negotiated  SOW,  and  "to  manage" 
their  work  according  to  the  SOW 
language. 

—By  legal  authorities  to  vindicate 
either  the  government  or  the  contrac¬ 
tor  regarding  contractual  disputes 
and  obligations. 

The  magnitude  of  these  objectives 
cannot  be  overstated.  The  SOW  is 
the  SPO  document  used  to  measure 
follow-on  schedules,  deliverables  and 
contractual  performance.  That's 
what  it  was  intended  to  be  and  that's 
what  history  has  repeatedly  proved. 
The  MIL-HDBK-245B  states  the  im¬ 
portance  of  the  SOW: 

After  the  contractor  has  been 
selected  and  the  contract 
awarded,  the  SOW  becomes 
the  standard  for  measuring  the 
contractor's  effectiveness.  As 
the  effort  progresses,  the  DOD 
and  the  contractor  will  con¬ 
stantly  refer  to  the  SOW  to 
determine  their  rights  and 
obligations  with  regard  to  con¬ 
tractor  response.  When  a  ques¬ 
tion  arises  concerning  an  ap¬ 
parent  increase  in  the  scope  of 


work  to  be  performed,  the 
SOW  is  the  baseline  document 
which  must  be  used  to  resolve 
this  question.  Language  in  the 
SOW  defining  the  scope  of 
outer  limits  of  the  contractor's 
effort  is  of  critical  importance 
at  this  time.  If  the  limits  were 
poorly  established,  it  will  be 
difficult  to  determine  if  or  when 
there  has  been  an  increase  in 
scope,  with  the  result  that  effec¬ 
tive  negotiations  on  cost  and 
schedule  will  be  impaired,  if  not 
impossible. 

How  should  program  managers  write 
an  effective  SOW?  By  necessity,  the 
program  manager  must  strive  to  pre¬ 
pare  SOWs  that  are  clear  concise  and 
unambiguous.  We  found  that  proper 
SOW  development  involves  5  funda¬ 
mental  steps: 

—Setting  government  and  contractor 
objectives  (acquisition  strategy) 

—Organizing  and  tailoring  SOW 
structure  (MIL-STD-881A) 

—  Writing  SOW  tasks  (MIL- 
HDBK-245B) 

—Negotiating  SOW  content  with  the 
contractor(s) 

—Changing  SOW  requirements  as 
the  program  evolves  (contract  change 
proposals,  engineering  change 
proposals). 

Each  step  is  important  but  we  focused 
emphasis  on  2  and  3.  We  feel  these 
are  the  "corporate"  weaknesses  in  Air 
Force  SOW  preparation. 

The  first  "do"  for  organizing  and 
tailoring  the  SOW  structure  concerns 
composition  of  the  SOW  preparation 
team.  Because  of  the  SOW  criticality, 
the  individual  selected  to  lead  the 
SOW  preparation  effort  should  be 
experienced  in  systems  acquisition 
and  SOW  development.  This  is  not 
the  time  to  be  looking  for  the  newest 
or  lowest-ranking  person  in  the 
organization.  Apparently  one  pro¬ 
gram  manager  used  our  survey  to 
frustration  on  this  exact  matter: 

"The  newest  lieutenant  gets  to  do  the 
next  SOW  (Air  Force  Rule  #212).'' 
The  same  thought  was  echoed  by 
many  program  managers  responding 
to  the  survey. 

Once  a  leader  is  identified,  the 
team  should  be  formed.  The  team 
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should  consist  of,  at  a  minimum,  a 
functional  expert  from  each  distinct 
discipline  that  will  have  taskings  in 
the  SOW.  The  initial  team  meeting 
should  be  directed  at  ensuring  com¬ 
plete  team  understanding  of  the  pro¬ 
gram  objectives,  acquisition  strate¬ 
gies,  user  requirements  and  areas  of 
responsibilities.  All  this  should  be 
done  before  the  first  SOW  words  are 
written.  Why  is  this  so  important? 

Well,  on  frequent  occasions  in  our 
SOW  review  consulting  efforts,  we 
find  SOWs  where  tasks  are  redun¬ 
dant,  obsolete  or  inconsistent.  For  in¬ 
stance,  does  it  make  sense  to  tell  a 
contractor  how  to  package,  handle 
and  transport  an  end-item  deliverable 
in  the  SOW,  and  in  the  contract  sched¬ 
ule,  and  ip  a  data  item  description, 
and  in  the  specification?  No! 

To  eliminate  possible  task  con¬ 
flicts,  a  contractor  should  only  be 
told  in  a  contract  one  time  to  perform 
a  specific  effort.  Multiple  tasking 
statements  lead  to  a  waste  of  contrac¬ 
tor  time  and  government  dollars,  and 
create  loopholes.  One  survey  respon¬ 
dent  so  stated: 

A  competent  team  needs  to  be 
created  and  committed  to  pro¬ 
ducing  a  quality  SOW,  Experi¬ 
ence  is  not  necessarily  best.  I've 
had  team  members  submit  SOW 
tasks  without  checking  to  see  if 
the  tasks  apply.  Common  sense 
(although  not  very  common)  is 
important.  For  example,  I  had 
an  "experienced"  team  member 
insist  on  adding  a  task  to  have 
the  contractor  write  a  report.  I 
asked  why  not  have  the  contrac¬ 
tor  revise  the  exis'ing  report  in¬ 
stead  of  writing  a  new  one  (this 
was  an  ongoing  effort).  My  big¬ 
gest  problems  have  been  getting 
everyone  to  agree  on  a  tailored 
SOW  (tailored  to  fit  the  re¬ 
quirements).  They  all  want  to 
add  their  standard  requirements 
even  if  it  doesn't  fit— "better  to 
have  too  much  than  not  enough" 
attitude. 

The  team  approach  is  necessary  be¬ 
cause  it  highlights  one  of  the  most  im¬ 
portant  ingredients  of  the  systems 
engineering  process— people.  It's  the 
people  who  make  the  program  work 
on  the  government  and  contractor 
sides.  Why  not  use  them  effectively? 


A  valuable  tool  for  development 
and  management  of  SOW  require¬ 
ments  is  the  work  breakdown  struc¬ 
ture  (WBS)  as  described  in  MIL- 
STD-881A.  We  found  the  WBS  to  be 
an  excellent  initial  starting  point  for 
organizing  and  tailoring  the  SOW 
and  identifying  interfaces  involved  in 
program  management.  Unfortu¬ 
nately,  today,  the  WBS  is  usually 
associated  with  the  cost-estimating 
field  and  given  the  stigma  of  being  a 
"bean  counter's"  responsibility.  This 
is  a  blatant  misuse  of  the  WBS.  The 
WBS  originally  was  developed  by 
systems  engineers  for  systems 
engineers.  Its  format  is  intended  to 
capture  years  of  experience  in 
weapon  systems  acquisition,  yet 
allow  enough  flexibility  for  a  SOW 
to  be  tailored  to  fit  individual  pro¬ 
gram  needs.  Ignoring  the  WBS  and 
what  it  can  do  for  you  may  be  put¬ 
ting  the  program  at  risk.  Program 
managers  were  asked  to  respond  to 
the  following  statement  in  our  earlier 
survey:  "One  of  the  first  steps  in 
developing  and  writing  the  SOW  is 
to  use  the  program's  current  Work 
Breakdown  Structure,  MIL-STD- 
881  A,  for  outlining  what  needs  to  be 
done." 

We  were  surprised  at  the  result.  Of 
the  1,088  responses,  54  percent 
agreed  that  the  WBS  was  a  valuable 
tool,  while  41  percent  did  not. 
Maybe,  at  least  in  part,  the  high  level 
of  disagreement  could  stem  from  a 
lack  of  previous  education  regarding 
the  WBS.  One  example  of  the  misun  • 
derstanding  existing  in  the  WBS  use 
can  be  seen  in  remarks  of  one  survey 
respondent.  "Shoehorning  every 
SOW  into  the  MIL-STD-881A  WBS 
categories  is  counterproductive.  It 
promotes  SOW  preparation  as  a  rote 
'cut-and-paste'  exercise  with  too  lit¬ 
tle  creativity.  As  a  result,  un¬ 
necessarily  rigid  task  procedures  tend 
to  be  called  out  and  too  much  data 
is  asked  for." 

The  WBS  format  was  never  in¬ 
tended  to  be  enforced  verbatim,  but 
used  as  a  starting  point  for  future 
tailoring  by  program  managers.  Rigid 
task  procedures  and  too  much  data 
are  issues  needing  to  be  resolved 
within  the  SPO  before  solicitation 
release  or  contract  award.  The  key 
point  is  that  the  WBS  does  not  drive 
our  requirements.  We  do.  It  merely 


provides  the  framework.  The  follow¬ 
ing  example  shows  how  the  WBS  can 
be  used  to  aid  in  SOW  formatting. 

Let's  take  a  fictitious  system,  the 
B-3  Bomber.  First,  the  upper  three 
levels  of  the  WBS  are  extracted  from 
the  appropriate  appendix  in  MIL- 
STD-881A.  In  our  case,  Appendix  A, 
or  Aircraft  WBS  (Figure  1).  This 
would  be  the  starting  point  for  tailor¬ 
ing  program  requirements.  To  orga¬ 
nize  our  program  requirements,  we 
must  have  an  established  acquisition 
strategy.  The  strategy  should  address 
such  things  as  level  of  competition, 
estimate  of  contract  value,  type  of 
contract,  time  phasing  and  program 
irn.  ntives. 

To  tailor  the  WBS  properly,  the 
SOW  preparer  must  understand  this 
strategy.  As  for  our  fictional  B-3 
Bomber  system,  we  could  have  the 
propulsion  subsystem  acquired  by  an 
engine  SPO  as  is  done  at  the  Aero¬ 
nautical  Systems  Division,  Wright- 
Patterson  AFB,  Ohio.  The  acquisi¬ 
tion  strategy  may  have  other  selected 
subsystems  broken  out  to  separate 
contractor,  like  was  done  for  the  of¬ 
fensive  and  defensive  avionics  suites 
on  the  B-1B,  while  the  airframe 
becomes  the  contractual  responsibil¬ 
ity  of  yet  another  contractor.  A 
serious  luestion  at  this  juncture 
becomes:  Who  will  be  the  overall 
system  integrator?  Will  it  be  the  air¬ 
frame  contractor  as  is  more  often  the 
case  or  will  it  be  by  design  or  by 
default,  relegated  to  the  government? 
These  issues  and  decisions  will 
become  the  foundation  for  the  prep¬ 
aration  of  the  WBS  that  ultimately  in¬ 
fluences  detailed  content  of  program 
SOWs. 

There  likely  will  be  other  organiza¬ 
tions  impacting  or  impacted  upon  by 
the  acquisition  process  and,  there¬ 
fore,  need  to  be  considered  in  the 
WBS  and  SOW  development.  As  ex¬ 
amples,  Air  Training  Command 
(ATC)  may  have  a  major  responsibil¬ 
ity  for  the  system  training  program 
and  it  may  be  necessary  to  integrate 
ATC's  level  of  participation  into  the 
SOW  requirements.  Equally  impor¬ 
tant  may  be  the  role  the  Air  Force 
Logistics  Command  may  play  by 
providing  the  contractor  with  com¬ 
mon  support  equipment  and  system 
components  currently  in  the  Air 
Force  or  DOD  inventory.  Will  the 
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FIGURE  1.  SUMMARY  AIRCRAFT  WBS  (MIL-STD-881A) 


LEVEL! 


LEVEL  II 


LEVEL  III 


needed  interfaces  with  these  other 
organizations  be  made  by  the  pro¬ 
gram  office  or  by  the  contractor?  The 
answer  will  certainly  affect  WBS  and 
SOW  content. 

How  does  the  contractor  break 
down  the  WBS  to  the  indentures 
below  the  top-three  selected  and 
tailored  by  the  government?  That  is 
part  of  their  system's  engineering  pro¬ 
cess.  Our  experience  has  been  that 


most  program  management  and  de¬ 
sign  problems  are  at  the  sixth  and 
seventh  levels  of  the  WBS,  which  are 
not  visible  at  the  aggregate  top-three 
levels.  Though  this  has  been,  at  best, 
a  cursory  look  at  the  formulation  of 
a  WBS,  the  major  points  still  remain. 

—The  WBS  helps  identify  inter¬ 
faces  within  the  government,  be¬ 
tween  the  government  and  contrac¬ 
tor,  and  between  contractors. 


—The  WBS  identifies  areas  of 
responsibility  regarding  funding, 
schedules  and  future  contract 
performance. 

—The  WBS  provides  a  framework 
for  integrating  total  program 
requirements. 

The  aircraft  WBS  format  in  Figure  1 
can  serve  as  an  excellent  starting  point 
for  SOW  development  (Figure  2).  For 


FIGURE!.  INITIAL  FICTIONAL  US  SOW  DEVELOPMENT 
USING  THE M IL-STD-SSJ A  AIRCRAFT  WES 
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instance.  Level  1  would  be  the  fic¬ 
tional  B-3  Bomber  System.  Level  2 
items  could  be  labeled  3.1  air  vehi¬ 
cle,  3.2  training,  3.3  peculiar  support 
equipment,  etc.  Level  3  items  would 
be  sequentially  numbered  using  the 
same  beginning  digits  as  its  higher- 
level  category;  the  airframe  could  be 
listed  as  3.1.1  under  the  air  vehicle  in¬ 
denture  3.1.  Once  all  levels  in  the 
WBS  are  numbered,  the  program 
manager  can  proceed  with  the  more 
complicated  effort  of  writing  the 
SOW  tasking  paragraphs.  As  men¬ 
tioned,  there  are  two  distinct  con¬ 
cerns  to  address  when  writing  a 
SOW.  One  is  preparation  of  a  SOW 
in  the  proper  format  that  follows  fun¬ 
damental  do's  and  don'ts  of  SOW 
construction.  The  other  is  proper 
wording  of  technical  and  managerial 
taskings  making  up  the  work  effort. 
Since  the  latter  is  the  more  difficult, 
how  do  program  managers  proceed 
with  this  arduous  undertaking?  Ac¬ 
cording  to  results  of  our  survey,  pro¬ 
gram  managers  agreed  that  the  most 
common  method  was  to  plagiarize 
from  another  program's  SOW.  One 
program  manager's  written  response 
typified  the  majority  perspective: 

It  was  common  practice  (in  my 
SPO)  to  try  to  copy  or  modify 
an  old  SOW.  Obviously,  unless 
the  programs  are  extremely  sim¬ 
ilar,  this  is  not  a  good  approach. 

There  are  inherent  risks  associated 
with  copying  an  existing  SOW, 
which  probab'v  was  tailored  to 
reflect  program-unique  requirements. 
Certainly  the  system  acquired  was 
unique.  There  may  have  been  dif¬ 
ferences  in  the  program  phases,  con¬ 
tract  type,  level  of  program  scope 
and  risk,  incentives,  or  other  pro¬ 
gram  areas.  A  SOW  is  a  derivative 
of  all  these  factors.  If  you  have  the 
necessary  skilled  resources  to  scrub- 
out  differences  between  the  other 
SOW  and  yours,  then  you  possess 
necessary  skills  to  develop  a  new 
SOW  using  a  systematic  approach 
without  reverting  to  plagiarism.  The 
use  of  another  SOW  as  a  source  of 
ideas  is  one  thing,  but  outright  copy¬ 
ing  without  strict  attention  to  ap¬ 
propriate  tailoring  could  leave  you 
with  the  same  result  as  is  suggested 
in  the  old  saying  about  computerized 
informational  databases— "Garbage 
In,  Garbage  Out  (GIGO)." 


Another  "do"  is  to  ensure  that  a 
SOW  task  makes  sense.  Try  to  look 
at  it  through  the  contractor's  eyes. 
Slightly  more  than  900  program  man¬ 
agers  out  of  1,036  agreed  that  the 
SOW  is  one  of  the  most  important 
documents  prepared  by  the  program 
office.  Vet,  in  our  SOW  preparation 
we  continue  to  include  tasks  not  well 
thought  out.  Here  are  actual  taskings 
taken  from  AFSC  contract  SOWs. 

Working  with  the  base  per¬ 
sonnel  at  each  base,  the  con¬ 
tractor  shall  determine  the 
scope  of  System  X  required  in 
order  for  the  base  to  reach  its 
initial  operational  capability 
(IOC). 

The  contractor  shall  support 
Air  Force  planning  efforts  by 
attending  meetings,  conferences 
and  reviews  and  responding  to 
requests  for  information. 

The  contractor  shall  conduct 
bimonthly  program  manage¬ 
ment  reviews  to  provide  a  re¬ 
view  of  the  contractor's  pro¬ 
gram  status  to  the  program 
office. 

The  contractor  shall  perform 
the  logistics  support  analysis 
(LSA)  process  in  accordance 
with  MIL-STD-1388-1A  and  es¬ 
tablish  an  LSA  Record  (LSAR) 
data  file  in  accordance  with 
MIL-STD-1388-2A.  (Note:  Tai¬ 
loring  of  the  MIL-STD-1388-1A 
taskings  and  1388-2A  data  base 
elements  will  be  accomplished 
at  the  LSA  guidance  conference). 


The  first  three  examples  are  vague 
and  ambiguous,  making  them  dif¬ 
ficult  to  price.  Will  the  contractor's 
pricing  be  a  true  and  accurate 
representation  of  a  government  re¬ 
quirement?  Example  three  has 
another  potential  problem  by  using 
the  word  “bimonthly.''  According  to 
the  American  Heritage  Dictionary, 
"bimonthly"  can  mean  once  every 
two  months  or  twice  a  month.  This 
may  be  a  mundane  example  but  it  un¬ 
questionably  points  out  the  need  to 
write  SOW  taskings  that  have  only 
one  interpretation.  It  would  have 
been  less  confusing  and  easier  to  price 
if  the  tasking  had  said  the  meeting 
would  be  conducted  twice  a  month 
or  every  two  months. 


In  the  last  example  above,  this 
SOW  requirement  was  found  in  a 
government  solicitation  officially 
released  to  industry  for  bid  propos¬ 
als.  The  problem  in  this  case  is  that 
an  LSA  guidance  conference  is  not 
held  until  after  the  contract  is 
awarded.  How  are  contractors  sup¬ 
posed  to  price  the  LSA  effort  com¬ 
petitively  when  the  government 
won't  be  finalizing  the  tasks  until 
after  the  contract  is  let?  Cost  of  per¬ 
forming  the  LSA  process  and  creation 
of  its  accompanying  data  base  is 
directly  dependent  on  how  many  of 
the  82  MIL-STD-1388-1A  subtasks 
must  be  accomplished,  and  which  of 
the  thousands  of  data  elements  con¬ 
tained  in  the  MIL-STD-1388-2A  data 
base  are  required.  Cost  of  the  LSA 
effort  can  fluctuate  by  millions  of 
dollars  on  a  large  program,  depend¬ 
ing  on  the  amount  of  MIL-STD  tai¬ 
loring  performed.  If  the  government 
did  not  want  to  do  the  tailoring,  it 
should  have  tasked  the  contractor  in 
the  "Instructions  to  Offeror"  (section  L) 
portion  of  the  solicitation  to  provide 
the  contractor's  recommended  tailor¬ 
ing  and  cost  in  their  proposal  re¬ 
sponse.  After  negotiations  are  com¬ 
plete,  proper  tailored  language  can  be 
inserted  into  the  final  SOW  contract. 

Some  of  you  may  be  thinking  the 
contractor  won’t  nickel-and-dime  us 
to  death.  They  understand  what  we 
want  and  will  live  up  to  the  spirit  of 
the  contract  not  the  letter  of  the  con¬ 
tract.  It  may  not  be  our  intention  or 
the  contractors,  but  when  we  put  am¬ 
biguous  words  and  requirements  in 
a  SOW,  we  make  contractors  mind- 
readers  and  may  put  them  in  control. 
Our  experience  has  shown  this  to  be 
possible,  especially  on  fixed-price 
type  contracts.  Providing  flexibility 
in  SOWs  should  be  something  that  is 
planned  and  in  the  best  interest  of  the 
program.  One  survey  respondent  sum¬ 
marized  this  way.  "SOWs  should  be 
in  adequate  detail  for  bidders  to  cost¬ 
out  the  effort,  but  broad  enough  to 
permit  flexibility  in  their  response; 
i.e.,  remember  to  convey  what  you 
want,  but  not  how  to  do  it." 

Another  common  problem  in  writ¬ 
ing  SOWs  is  the  improper  tasking  of 
the  contractor  to  prepare  data  re¬ 
quirements.  Both  AFR  310-1  and 
MIL-HDBK-245B  state  that  data  are 
by-products  of  the  work  generated  by 
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the  contractor's  performance  of  SOW 
tasks.  Data  are  to  be  ordered  in  the 
Contract  Data  Requirements  List 
(CDRL)  and  only  a  reference  to  the 
data-item  description  identification 
number  (DI-CMAN-80008)  or  the 
CDRL  sequence  number  will  be 
referenced  at  the  end  of  a  SOW 
tasking. 

During  a  consulting  effort  involv¬ 
ing  review  of  a  draft  SOW  for  a 
major  aircraft  acquisition  program, 
we  identified  59  separate  SOW  task- 
ings  directing  the  contractor  to 
prepare  data.  Of  greater  concern:  In 
two  of  them  the  contractor  was 
tasked  to  develop  acceptance  test 
procedures  (ATP)  and  a  configura¬ 
tion  management  plan.  Nowhere  in 
the  SOW  was  the  contractor  told  to 
perform  the  ATP  or  to  establish  and 
implement  a  configuration  manage¬ 
ment  program.  The  contractor  should 
have  been  tasked  in  the  SOW  to  "per¬ 
form  acceptance  test  procedures  IAW 
the  governments  approved  plan"  and 
"establish  and  implement  a  con¬ 
figuration  management  program." 
The  data  by-products  of  this  effort 
would  be  the  ATP  and  configuration 
management  plan  data  deliverables 
as  ordered  in  the  CDRL.  The  contrac¬ 
tor  would  know  of  the  data  require¬ 
ment  needing  development  by  the 
parenthetical  reference  to  the  data- 
item  numbers  at  the  end  of  the  SOW 
task.  A  simple  thought  to  remember: 
Any  data  deliverables  ordered  in  the 
CDRL  should  not  be  identified  in  the 
SOW  as  a  direct  tasking  for  its 
development.  This  would  include 
simple  data  products  like  agendas 
and  minutes  up  to  expensive  ones  like 
engineering  drawings.  Here  are  ex¬ 
amples.  Incorrect:  The  contractor 
shall  prepare  computer  program  test 
plans  and  procedures  for  integration 
of  the  built-in-test  software  into  a 
central  processing  subsystem.  (DI- 
XXX-XXXXX)  Correct:  The  contrac¬ 
tor  shall  integrate  and  test  the  built- 
in-test  software  in  the  central  process¬ 
ing  subsystem.  (DI-XXX-XXXXX) 

In  the  incorrect  example  the  task  is 
to  "prepare  plans  and  procedures,"  in 
other  words  DATA.  Where  is  the  con¬ 
tractor  actually  tasked  to  perform  the 
integration  or  test?  In  the  correct  ex¬ 
ample,  the  contractor  is  tasked  to  do 
the  "integration  and  testing”  and  the 
plans  and  procedures  are  the  data  by- 


The  team  approach 
is  necessary 
because  it 
highlights  one  of 
the  most  important 
ingredients  of  the 
systems  engineering 
process-— people. 

It's  the  people  who 
make  the  program 
work  on  the 
govern  we  til  mol 
couhifct or  Attire. 

Why  not  use  Ihrui 
cflecltvetif'' 

products  of  the  planning  of  these  ac¬ 
tivities.  The  contractor  is  made  aware 
that  a  data  product  relevant  to  this 
particular  work  effort  has  been  or¬ 
dered  in  the  CDRL  by  the  parenthet¬ 
ical  reference  to  the  data  item  at  the 
end  of  the  SOW  task  statement.  These 
examples  illustrate  the  relationship 
that  must  exist  between  the  SOW  and 
data  by-products.  The  SOWs  need  to 
be  coordinated  with  all  functional 
managers  so  that  data  requirements 
can  be  combined,  reduced  or 
eliminated. 

Education 

Education  and  practical  experience 
in  SOW  preparation  are  the  best  way 
to  overcome  some  problems  we 
described.  Though  we  have  been  ad¬ 
dressing  the  problem  of  SOW  devel¬ 
opment,  the  problem  is  much  deeper. 
If  you  don't  have  a  well-rounded 
understanding  of  acquisition  prin¬ 
ciples  and  processes  it  will  be  difficult 
to  write  a  SOW.  Recent  initiatives 


resulting  from  the  defense  manage¬ 
ment  review  (DMR)  have  highlighted 
the  need  for  better  trained  DOD  pro¬ 
gram  managers  and  acquisition  sup¬ 
port  personnel.  The  DMR  grew  out 
of  findings  from  the  1986  Packard 
Commission  Report,  which  stressed 
the  need  for  acquisition  reform  and 
improved  educational  opportunities 
for  acquisition  support.  In  fact,  the 
Air  Forces  Acquisition  Management 
Professional  Development  Program 
(AMPDP)  was  a  direct  outgrowth  of 
the  Packard  Report.  The  AMPDP 
sets  stringent  guidelines  for  certifying 
acquisition  personnel  at  three  levels, 
which  are  indicative  of  their  educa¬ 
tional  and  experience  background. 
Unfortunately,  the  courses  required 
in  this  certification  curriculum  are  far 
from  adequate  in  meeting  the  need 
for  SOW  preparation. 

The  Defense  Systems  Management 
College  (DSMC)  Program  Manage¬ 
ment  Course  highlights  the  SOW  and 
its  relationship  to  SPO  objectives. 
Periodically,  DSMC  will  conduct 
two-  or  three-day  system  engineering 
seminars  where  SOW  preparation  is 
part  of  the  curriculum.  We  partici¬ 
pated  in  one  of  these  seminars  at  the 
Human  Systems  Division,  Brooks 
AFB,  Texas,  and  found  it  to  be  a  very 
effective  way  of  training. 

The  Air  Force  Institute  of  Technol¬ 
ogy  (AFIT)  has  courses  regarding 
SOW  development.  The  AFIT  SYS 
100  course  is  a  30-hour  introduction 
to  general  program  management  re¬ 
sponsibilities  with  a  cursory  discus¬ 
sion  of  the  SOW  and  its  purpose.  The 
AFIT  3-week  SYS  200  course  of  ap¬ 
proximately  12  hours  on  basic  SOW 
preparation  skills  includes  practical 
exercises.  Although  SYS  200  concerns 
SOW  development,  available  slots  to 
attend  the  course  are  limited  at  this 
time  to  about  300-350  students  per 
year.  Considering  the  backlog  of 
students  wanting/needing  to  attend, 
it  doesn't  appear  there  are  over¬ 
whelming  opportunities  available  for 
education  or  training  on  proper  SOW 
development  techniques. 

There  are  several  automated  tools 
available  within  the  government  to 
assist  in  SOW  preparation.  The  most 
well-known  is  the  modem  accessible 
computer  generated  acquisition 
documentation  system  (CGADS), 
( Continued  on  page  38) 
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RELIABILITY 


APPLYING  TOTAL  QUALITY 
MANAGEMENT  TO  THE 
SOFTWARE  LIFE  CYCLE 


r  •>:<!>  \lhu,hi  know  how  soft- 
■  '•••■  ■  non  uni  nnpnci  on  ihr 


pplying  Total  Quality 
Management  (TQM)  con¬ 
cepts  to  software  development  pro¬ 
cesses  can  dramatically  improve  our 
competitive  advantage  in  the  soft¬ 
ware  arena.  By  capitalizing  on  the 
TQM  approach,  (i.e.,  designing  and 
building  quality  into  software,  en¬ 
dorsed  in  DoD-STDs  2167A  and 
2168),  a  process  is  established  that  en¬ 
courages  error  prevention  and  reduc¬ 
tion,  and  fosters  earjy  error  iden¬ 
tification  and  resolution.  Increased 
software  development  efficiency 
(productivity)  also  promotes:  better 
understanding  of  the  development 
environment  and  system  require¬ 
ments;  reduced  test  through  increased 
evaluation  effectiveness  (i.e.,  testing 
smarter,  not  more);  and  quantifiable 
measures  for  the  evaluation  process. 
This  contributes  to  reducing  acquisi¬ 
tion  and  support  costs  by  advocating 
a  total  life-cycle  approach  to  software 
development,  including  modification 
efforts  after  the  system  is  fielded 
(Figure  1). 

Setting  the  Stage 

As  software-intensive  systems  con¬ 
tinue  to  dominate  modern  commer¬ 
cial  and  defense  system  applications, 
software  development,  test,  and 
evaluation  play  an  ever  expanding 
role  in  overall  system  planning  and 
execution.  Accordingly,  it  is  im¬ 
perative  that  the  system  development 
community  have  an  understanding  of 
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how  software,  and  total  quality 
management  application  to  the  soft¬ 
ware  processes  and  products,  can  im¬ 
pact  the  total  integrated  systems 
ability  to  meet  technical,  cost, 
schedule,  operations  and  support 
objectives. 

As  TQM  becomes  increasingly  in¬ 
stitutionalized  within  commercial  and 
defense  development/acquisition 
processes,  it  is  important  to  recognize 
that  the  TQM  philosophy  is  equally 
applicable  to  the  system's  hardware 
and  software  elements.  However,  it 
must  be  understood  that  TQM 
leverage  areas  are  different  for  hard¬ 
ware  and  software,  thereby  influ¬ 
encing  planning  and  execution.  While 
the  TQM  philosophy  is  the  same  for 
all  system  elements,  applying  TQM 
to  software-intensive  systems  re¬ 
quires  a  different  perspective  to  in¬ 
stall  and  maintain  management  com¬ 
mitment  to  continuous  improvement. 


Total  quality  management  takes  a 
total  life-cycle  view  of  system 
development  and  production  (Figure 
2).  For  production  programs, 
material,  labor  and  overhead 
dominate  life-cycle  production  costs. 
However,  design  and  development  is 
the  predominant  influence  on  life- 
cycle  costs,  with  the  smallest  percent¬ 
age  of  life-cycle  product  cost.  Many 
of  today's  total  quality  management 
practitioners,  across  the  full  product 
process  spectrum,  while  not  ignoring 
design  and  development,  concentrate 
on  improvement  in  the  material  (pro¬ 
duction),  labor  (also  production 
related)  and  overhead  aspects.  This, 
in  part,  may  be  due  to  the  back¬ 
ground  of  many  of  today's  senior 
managers  and  their  familiarity  with 
hardware  manufacturing. 

While  this  perspective  is  valid  for 
the  hardware  elements  of  the  finished 
product,  it  must  be  noted  that  it  is  not 
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applicable  for  the  system's  software 
elements.  For  example,  software  pro¬ 
duction  costs  are  basically  negligible 
when  compared  to  hardware  produc¬ 
tion  costs.  In  fact,  the  major  element 
of  software  production  costs  is  cost 
associated  with  hardware;  i.e.,  elec¬ 
tronic  media  (disks,  read-only- 
memory)  used  to  deliver  software  to 
the  user. 

Software  may  be  different  but  it 
does  not  mean  software  is  un¬ 
manageable.  Consequently,  a  pro¬ 
duct’s  software  elements  also  can 
benefit  from  total  quality  manage¬ 
ment  application,  when  differences 
are  recognized,  understood;  also 
when  management  makes  a  con¬ 
scious  decision  to  pro-actively 
manage  and  improve  all  processes 
and  product  elements  associated  with 
providing  quality  products  to  their 
customers.  This  improves  their  com¬ 


petitive  advantages  within  either,  or 
both,  commercial  and  defense 
sectors. 

Applying  total  quality  manage¬ 
ment's  total  life-cycle  perspective  to 
the  system's  software  elements,  while 
recognizing  differences  associated 
with  the  software  life  cycle,  presents 
a  different  set  of  considerations  and 
process  areas  for  exploitation  in 
achieving  continuous  improvement 
(Figure  3).  For  example,  there  is  a 
direct  correlation  between  effort  ex¬ 
pended  and  product  costs,  with  no 
significant  impact  on  the  relative 
percentages.  However,  effort  ex¬ 
pended  directly  acknowledges  the 
labor-intensive  activities  associated 
with  software  development,  opera¬ 
tions  and  maintenance. 

It  is  easily  recognized  that  four 
leverage  areas,  requirements  analysis, 
design  code  and  unit  test,  and  in¬ 
tegration  and  test  are  directly 
associated  with  the  software  develop¬ 
ment  process.  Therefore,  one  could 
say  that  while  operations  and 
maintenance  clearly  dominate  soft¬ 
ware's  total  life-cycle  effort,  develop¬ 
ment  is  the  predominant  influence  on 
life-cycle  effort. 

Understanding  software  operations 
and  maintenace  activities  can  further 
clarify  ''true"  software  leverage  areas. 
Typical  operations  and  maintenance 
functions  are:  identifying  and  correc¬ 
ting  previously  existent  errors,  faults 
or  failures  undetected  during  initial 
development  and  test  or  maintenance 
and  test;  improving  system  perfor¬ 
mance  without  adding  new  capa¬ 
bilities  (e.g,,  changes  to  account  for 
system  hardware  enhancements  or 
shortfalls),  or  to  improve  user  inter- 
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faces;  and  enhancements  to  add  new 
performance  capabilities.  All  these 
are  just  different  forms  of  software 
development  activities. 

Since  software  operations  and 
maintenance  are  basically  another 
form  of  development,  it  is  possible  to 
improve  software's  life-cycle  costs 
and  product  quality  by  focusing  on 
improving  software  development  ac¬ 
tivities  and  applying  development 
process  improvements  to  the  opera¬ 
tions  and  maintenance  phase.  This 
has  three  benefits:  development  pro¬ 
cess  improvements  should  produce 
higher  quality  software  that  meets 
user  needs  in  the  operational  environ¬ 
ment;  higher  quality  software  should 
require  less  maintenance  to  correct 
previously  existent  errors,  faults,  and 
failures;  and  improving  the  software 
maintenance  (development)  process 
should  produce  higher  quality  soft¬ 
ware  that  meets  the  user’s  needs  with 
reduced  errors,  faults  and  failures. 

Applying  TQM  techniques  to  soft¬ 
ware  development  presents  a  further 
refined  set  of  process  activities  for 
analysis  and  improvement  (Figure  4). 
As  used  here,  ''definition''  includes  re¬ 
quirements  analysis;  "design"  is  the 
application  of  software  engineering 
discipline  to  translate  requirements 
into  a  detailed  “blueprint"  that  meets 
the  requirements;  "development"  is 
the  code  ("manufacture")  and  integra¬ 
tion  of  the  software  components  into 
a  functional,  quality  software  pro¬ 
duct;  test  is  the  full  gamut  of  activities 
associated  with  evaluating  software's 
quality  and  performance  levels  from 
the  unit  level  to  the  integrated,  final 
product;  and  "pre-production"  costs 
could  be  from  either  initial  develop- 
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FIG.  2.  TQM  LEVERAGE  AREAS 
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merit  or  specific  software  main¬ 
tenance  (development)  activities. 
Again,  there  is  a  dichotomy,  for 
while  definition  has  the  largest  in¬ 
fluence  on  software  cost,  test  is  the 
single  largest  opportunity  for  cost 
reduction. 

Software  definition  adequacy, 
degree  of  software  engineering 
discipline  applied  during  design,  and 
development  process  quality  directly 
influence  the  extent  and  nature  of 
software  planning,  execution,  and 
evaluation.  These  interrelationships 
are  important,  especially  in  develop¬ 
ing  and  maintaining  today's 


software-intensive  systems,  where 
there  is  an  up-front  emphasis  on 
designing-in  quality,  instead  of 
testing  quality  into  the  product  before 
customer  delivery.  Rigorous  applica¬ 
tion  of  discipline  and  process 
knowledge  will  help  to  ensure  that 
quality  software-intensive  system 
delivery  to  the  customer  is  the  norm 
and  not  an  exception. 

Prerequisites 

A  1982  Defense  Science  Board 
(DSB)  report*  concluded  that 
multifaceted  problems  were 
associated  with  software  develop¬ 


ment,  but  concentrated  in  two  areas: 
management  and  status  measure¬ 
ment.  Similar  concerns  were 
expressed  in  a  1987  DSB  report,2 
"Big  problems  are  not  technical.  In 
spite  of  substantial  technical  develop¬ 
ment  needed  in  requirements-setting, 
metrics  and  measures,  tools,  etc.,  the 
Task  Force  is  convinced  that  today's 
major  problems  with  military  soft¬ 
ware  development  are  not  technical 
problems,  but  management  pro¬ 
blems."  These  DSB  reports  were  reaf¬ 
firmed  by  a  1988  Software  Engineer¬ 
ing  Institute  (SEI)  report3  which  con¬ 
cluded,  "not  much  change  since 
1982,"  but  there  was  a  "better 
understanding  of  problems." 

Software  development  strategies' 
apparent  failure  to  keep  pace  with 
the  rapid  software  technology  inser¬ 
tion  growth  is  an  argument  often 
raised  against  many  large-scale, 
software-intensive  defense  weapon 
systems.  Opponents  claim  it  is  im¬ 
possible  to  build  perfect  systems  due 
to  the  magnitude  of  the  software 
task.  This  can  be  countered  by:  (1) 
striving  for  perfection  while  recogniz¬ 
ing  limitations  imposed  by  human 
foibles,  and  (2)  defining  and  achiev¬ 
ing  an  end-goal,  not  of  perfection, 
but  of  satisfying  customers  needs 
(requirements). 

Effective  software  development 
planning  and  execution  must  address 
four  issues  directly  associated  with 
TQM:  (1)  Where  are  you  now? 
Define  the  known  process,  system 
technical  and  performance  baselines, 
and  current  development  status;  (2) 
Where  are  you  trying  to  go?  Define 
the  development  effort's  process, 
technical  and  operational  perfor¬ 
mance  objectives  to  be  verified;  (3) 
How  are  you  going  to  get  there? 
Define  the  measurement  and  evalua¬ 
tion  program  that  will  provide  quan¬ 
titative  evidence  to  support  process 
improvement,  risk  management  and 
fielding  of  viable  weapon  systems; 
and  (4)  How  do  you  know  when 
you're  there?  Define  the  measures  of 
merit  that  will  be  used  to  validate 
achievement  of  process,  performance 
and  technical  objectives. 

Successful  TQM  activities  (i.e., 
ones  striving  for  continuous  process 
and  product  quality  improvement) 
effectively  use  evaluation,  measure¬ 
ment  and  test  tools  to:  assess  prc  cess 
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FIG.  4.  SOFTWARE  DEVELOPMENT 


Percent  of  Pre-production  costs 


status  and  product  quality;  foster 
early  error  identification  and  correc¬ 
tion;  and  continuously  apply  error 
prevention  methodologies.  This  com¬ 
bination  of  TQM  practices  and  viable 
implementation  procedures  is 
available  today.  Using  it  provides 
quantifiable  measures  to  build  con¬ 
fidence  and  traceability  during  the 
system's  life  cycle  and  forms  a  basis 
for  an  improved  software  develop¬ 
ment  and  evaluation  process,  and 
true  software-intensive  system 
acquisition  strategies. 

To  compare  software  development 
strategies,  a  basis  for  comparison  is 
needed.  A  natural  choice  is  cost,  from 
perspectives  of  development  cost  and 
the  cost  of  errors  (in-efficiencies)  (see 
Table  1)  for  each  life-cycle  phase.  For 
each  evolutionary  strategy  an 
estimate  of  software  development 
and  error  costs  are  presented  by  life- 
cycle  activity.  Error  is  defined  in 
ANSI /IEEE  Standard  729-1983, 
"IEEE  Standard  Glossary  of  Software 
Engineering  Terminology,”  as 
follows:  "Human  action  that  results 
in  software  containing  a  fault.  Ex¬ 
amples  include  omission  or  misinter¬ 
pretation  of  user  requirements  in  a 
software  specification,  incorrect 
translation  or  omission  of  a  require¬ 
ment  in  the  design  specification." 

Development  costs  were  obtained 
using  the  COCOMO  software 
estimating  model  for  a  100,000  line 
of  code  (LOC)  effort.  COCOMO 


(Constructive  COst  MOdel) 
developed  by  Dr.  Barry  W.  Boehm 
is  described  in  Endnote  7.  Based  upon 
data  collected  on  completed  software 
development  efforts,  it  includes 
development  error  detection  and  cor¬ 
rection.)  Nominal  settings  were  used 
for  all  development  environment  fac¬ 
tors,  except  product  reliability,  which 
was  set  at  1.15  to  reflect  military 
system  application,  and  use  of  pro¬ 
gramming  practices,  which  were  set 
at  1.24  for  traditional,  1.0  (nominal) 
for  modern,  and  0.82  for  projected. 
For  comparison,  a  constant  dollar 
figure,  $73.00.  labor  hour,  was  used. 


Error  costs  and  savings  due  to 
error  prevention  techniques  were 
calculated  using  the  following 
assumptions  (in  terms  of  errors  re¬ 
maining  at  time  of  initial  software 
operation  and  maintenance,  these 
assumptions  are  consistent  with  data 
presented  by  Bush4). 

Humphrey5  showed  that  up  to  80 
percent  of  developed  software  is  error 
free.  Applying  this  to  100,000  LOC 
implies  that  20,000  LOC  are  affected 
by  errors,  but  all  errors  do  not  affect 
just  one  line  of  code;  i.e.,  one  should 
not  infer  20,000  errors.  It  was 
assumed,  on  average,  one  error  af- 
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fected  five  lines  of  code;  e.g.,  the 
possibility  exists  for  4,000  errors. 

Error  correction  cost  is  based  upon 
actual  data  from  Tiburon  Systems, 
Inc.6  The  cost  ratio  across  the  cycle 
phases  is  consistent  with  data 
presented  by  Boehm.7  Error  inser¬ 
tion  distribution  is  obtained  directly 
from  Table  1,  slightly  modified  to 
recognize  changes  in  phase  ter¬ 
minology  and/or  breakout. 

Productivity  measures  are  tradi¬ 
tionally  based  upon  LOC/day  or 
document  pages/day,  etc.  Here,  a 
non-traditional  measure  is  proposed 
in  terms  of  process  efficiencies  for 
preventing  and  detecting  errors 
during  the  life  cycle.  This  measure 
can  be  a  better  criterion  for  assessing 
productivity  from  the  standpoint 
that,  while  rate  of  product  develop¬ 
ment  is  important,  product  quality  is 
the  productivity  driver.  Process  effi¬ 
ciencies  for  modern  practices  are  ob¬ 
tained  from  Table  1,  modified  as 
above.  Efficiencies  for  traditional 
practices  reflect  late  life-cycle  phase 
use  of  test  to  determine  and  improve 
product  quality  then  in  vogue.  Pro¬ 
jected  strategy  efficiencies  reflect 
gains  expected  with  consistent,  effec¬ 
tive  application  of  the  Ada  environ¬ 
ment,  TQM  management  practices 
contained  in  DOD-STDs  2167A  and 
2168,  and  true  application  of  soft¬ 
ware  engineering  discipline  based 
upon  applied  mathematics. 

Error  prevention  efficiencies  were 
arbitrarily  picked  for  traditional 
practices.  Efficiencies  were  modified 
for  modern  and  projected  strategies 
to  reflect  anticipated  changes  in  error 
prevention  efficiency  associated  with 
application  of  TQM  and  improved 
development  practices.  Note:  Actual 
error  prevention  efficiency  data  are 
unavailable. 

In  addition  to  development  cost,  it 
is  imperative  to  consider  software 
development  strategy  evolution  in 
terms  of  a  parametric  model.  For  ex¬ 
ample,  the  formula  for  successful 
software  development  can  be 
expressed  as:  Software,  productivity, 
management,  and  quality  equal  im¬ 
provement  of  people,  policy,  process, 
procedure  and  planning, 

As  software  development  strategies 
evoked,  each  strategy  can  be 
characterized  by  functional  areas  that 


were  improved.  However,  all  areas 
were  not  necessarily  addressed  in  any 
particular  phase.  Despite  improve- 
mens  in  one  or  more  functional  areas, 
failure  to  improve  any  one  area  can 
negate  improvements  in  others.  This 
is  consistent  with  SEI  methodologies 
to  measure  the  capability /capacity  of 
software  developers  to  produce  qual¬ 
ity  software  products.8  Accordingly, 
the  appropriate  SEI  process  level 
maturity  is  identified  for  each  evolu¬ 
tionary  strategy. 

Traditional  Approach 
(SEI  Process  Level  1) 

A  Level  1  (initial)  organization  has 
ill-defined  procedures  and  controls. 
The  organization  does  not  consis¬ 
tently  apply  software  engineering 
management  or  use  modern  tools  and 
technology,  and  may  have  serious 
cost  and  schedule  problems.  Tradi¬ 
tional  development  is  identified  by: 
(1)  perceived  infinite  software  flex¬ 
ibility;  (2)  lack  of  formal  engineering 
(art  verses  science);  (3)  lack  of  pro¬ 
cess  controls  and  management 
visibility  techniques;  (4)  continuous 
software  development  is  typically  at¬ 
tempted,  in  essence,  the  prototype  is 
the  deliverable  end-item;  and  (5) 
while  hardware  requirements  are 
"frozen"  prior  to  build,  software  re¬ 
quirements  change  throughout  the 
development  process. 

At  least  seven  out  of  ten  major 
defense  programs  using  the  tradi¬ 
tional  approach  strategy  experience 
critical  software-related  problems 
that  directly  impact  system-level  cost, 
schedule  and  performance.9  Tradi¬ 
tional  approach  strategy  attributes 
can  be  related  to  a  combination  of 
fear,  mysticism  and  mythology.  Fear 
arises  from  computer/software 
technologies  and  terminology.  A 
direct  outgrowth  of  fear  is  the 
mystique  that  these  technologies  can 
only  be  understood  by  software 
wizards,  not  system  managers.  This 
mixture  produces  myths  that,  over 
time,  were  proved  to  be  wrong  and 
costly. 

Myths  are  often  stated  as  follows: 
(1)  Software  only  affects  computers, 
not  the  system;  (2)  understanding 
software's  impact  on  system  perfor¬ 
mance  is  easily  achieved,  (3)  test 
methodologies  can  easily  detect, 
classify  and  allocate  sy  stem  errors  to 


software;  (4)  test  detects  all  software 
errors  since  the  computer  won't  run 
if  an  error  exists;  (5)  softvv  -e  is  in¬ 
herently  flexible,  therefore  changes 
and  corrections  are  easy;  and  (6)  soft¬ 
ware  performance  requirements  can¬ 
not  be  stated,  measured  or  evaluated. 

Traditional  software  development 
"strategies"  are  an  "art  form."  Soft¬ 
ware  is  designed  from  the  bottom  up 
(from  what  developers  already  know, 
e.g.,  algorithms,  equations,  for¬ 
mulas,  etc.)  to  what  was  now  re¬ 
quired;  and  tested  by  a  best  "guess" 
approach  to  what's  required.  When 
problems  are  found,  software  is  fixed 
by  programming  judgment.  This 
haphazard  method  produces 
monolithic,  disjoint,  complex  pro¬ 
grams  full  of  "patches,"  "band-aids" 
and  "nifty  tricks." 

Monolithic,  disjoint  structures 
often  have  "horror  story"  glitches, 
true  development  status  or  un¬ 
discovered  critical  errors  that  are 
seldom,  if  ever,  found.  Problems  are 
left  for  the  user  to  find.  Software 
often  is  not  properly  tested,  implying 
either  systems  test  or  nothing  at  all, 
except  for  problems  discovery  in 
compilation  and/or  assembly.  Little 
or  no  management  visibility  into  the 
software  development  process'  pro¬ 
gress,  status  and  problems  exists. 

Programmers,  software  engineer¬ 
ing  predecessors,  have  great  freedom 
from  controls.  No  one,"  knows  the 
jargon  or  how  to  develop  software. 
Management's  process  and  technical 
performance  visibility,  per  se,  is 
nonexistent.  Software  is  a  "black 
art,"  not  engineering  discipline,  prac- 
ticed  by  "wizards."  Common 
measurement  practices  are  the  "90 
percent  Syndrome."  ("90  percent 
Syndrome"  refers  to  the  generic 
answer  for  all  software  development 
questions.  Where  are  we  now?  What 
remains  to  be  done?  When  will  we  be 
done?  The  answer  was:  "The  soft¬ 
ware  is  90  percent  done.”  There  is  no 
difference  when  these  are  considered, 
development  beginning,  during,  or 
end;  after  fielding;  or  when  the  soft¬ 
ware  was  retired.  The  answer  re¬ 
mained  the  same.) 

As  software  life-cycle  costs  grow, 
the  traditional  approach  is  becoming 
unacceptable  and  unaffordable.  Con¬ 
sider  the  h>  pothetical  100,000  LOC 
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TABLE  2.  TRADITIONAL  SOFTWARE  DEVELOPMENT  APPROACH 


EFFICIENCIES 
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1 
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j  ERROR  1 

ERROR 

TEST  &  |  PRO- 
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ERRORS 

|  ERRORS 

j  ERRORS 

COST/ 
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TRADITIONAL 

EVAL  j  CESS 
.........  1 . 

1 

ERRORS 

PREVENTED 

j  REMOVED 

j  PASSED 

ERROR 

j  COST  j 
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1 

0.00%  I  5.00% 

1 

2,200 

110 

i  o 

1  2,090 

380 
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41,800 
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0.00%  |  25.00% 

! 
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j  0 

I  2,690 

380 
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1 
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60 

j  969 

I  2,261 
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|  923,457  I 
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1 

200 

50 
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1  1,206 
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|  1,148,842  | 

47,650 
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X 

200 

70 
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I 
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490 
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1 

1 

1 
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1 
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J _ 

J _ 

J _ L 

COCOMO  COST  ESTIMATE:  $17,639,294 


program  (Table  2).  The  historical  ap¬ 
proach  requires  $17.6  million  for 
development.  Error  correction  costs 
incurred  are  $4.1  million,  or 
approximately  24  percent  of  develop¬ 
ment  cost.  Error  prevention  activities 
avoided  less  than  SO. 36  million  in 
incurred  costs.  From  a  life-cycle 
perspective,  total  cost  incurred  due  to 
errors  is  in  excess  of  57.8  million,  or 
44  percent  of  development  cost. 

Current  Approach 
(SEI  Process  Level  2-3) 

A  Level  2  (repeatable)  organization 
has  learned  to  manage  cost  and 
schedule,  has  a  repeatable  process 
and  uses  standard  methods  and  prac¬ 
tices  for  managing  software  develop¬ 
ment  activities;  e.g.,  cost  estimating, 
scheduling,  requirements/code 
changes,  and  status  reviews.  At  Level 
3  (defined),  the  process  is  character¬ 
ized  and  reasonably  understood.  The 
organization  defines  its  process  soft¬ 
ware  engineering  standards  and 
methods,  and  makes  a  series  of  pro¬ 
cess  improvements,  including;  design 
and  code  reviews,  training  programs, 
and  increased  commitment  to  soft¬ 
ware  engineering.  A  major  improve¬ 
ment  over  Level  2  is  the  establishment 
and  staffing  of  a  process  improve¬ 
ment  group  that  focuses  on  software 
engineering  (based  on  applied 
mathematics,  not  art),  the  software 
engineering  process,  and  the  ade¬ 
quacy  with  which  it  is  implemented. 


The  current  approach  is 
characterized  by;  (1)  disciplined  soft¬ 
ware  design  processes  to  replace 
monolithic  design  practices;  (2)  ef¬ 
forts  to  obtain  quantifiable  software 
measures;  and  (3)  early  stage  applica¬ 
tion  of  Ada,  including  the  Ada 
development  environment,  and  struc¬ 
tured,  consistent  software  develop¬ 
ment,  quality,  test  and  evaluation 
practices,  and  software  measure¬ 
ment. 

Ada  promotes  proactive  engineer¬ 
ing  discipline  in  the  software  develop¬ 
ment  process.  The  Ada  environment 
adds  an  "object-oriented"  perspective 
to  the  traditional  "top-down"  ap¬ 
proach  to  requirements  definition 
and  implementation.  This  enhances 
the  requirements  definition  and 
analysis  processes  by  producing 
quantitative,  objective  requirements 
and  performance  levels;  i.e.,  quality 
attributes,  to  be  measured  and 
verified  through  test,  analysis  and 
evaluation. 

The  DOD-STDs  2167A  and  2168 
define  management  structure,  not 
technical  structure,  for  software 
development  and  support;  and  pro¬ 
vide  a  consistent  DOD  approach  for 
implementing  viable  evaluation 
techniques.  Capitalizing  on  these 
standards,  DOD  5000.3-M-3  pro¬ 
vides  for  incorporating  software 
reliability,  test,  and  evaluation  into 
defense  sy  stem  planning  activities  by 


requiring  defense  system  developers 
to  identify  specific  software  perfor¬ 
mance  objectives  in  a  system’s  con¬ 
text  and  measures  of  merit  to  verify 
objective  achievement. 

Software  measurement  directly 
relates  to  the  ability  to  obtain 
visibility  into  the  development  pro¬ 
cess  and  products.  Complexity  and 
perceived  data  intensiveness 
associated  with  using  the  DOD- 
STD-2167A  software  quality  factors 
have  inhibited  domestic  software 
measurement  applications.  While 
software  measurement  has  not 
reached  a  maturity  which  allows  con¬ 
sistent  interpretations  of  each  factor, 
early  application  of  metrics  have  pro¬ 
vided  preliminary  results  that 
indicate  direct  linkage  between 
measurement,  management  visibility, 
and  reduced  development  costs. 
When  organizations  recognize  this 
linkage  between  measurement  and 
active  management  process  control 
and  improvement  and  initiate  a  soft¬ 
ware  measurement  program  respon¬ 
sive  to  management  needs,  they  take 
a  large  step  in  progressing  from  Level 
2  to  Level  3. 

Software  indicators  counter  the 
perceived  data  intensiveness  of  soft¬ 
ware  measurement,  and  provide 
management  insight  into  develop¬ 
ment  process  and  software  product 
quality.  Indicators,  though  not  ab¬ 
solute,  combine  planning  goals  and 
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TABLE  3 .  CURRENT  SOFTWARE  DEVELOPMENT  APPROACH  COSTS 


EFFICIENCIES  | 
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COCOHO  COST  ESTIMATE:  *14,225,237 


trend  data  to  enhance  the  evaluation 
process,  provide  status  assessment 
tools,  and  data  for  research  com¬ 
munity  use  in  calibrating  software 
metrics.  Originally  published  as  Air 
Force  Systems  Command  Pamphlets 
800-14  and  800-43,  the.  Army 
Materiel  Command  has  adopted  this 
concept,  and  the  Navy  is  preparing 
their  versions  of  these  documents. 
The  Institute  of  Electrical  and  Elec¬ 
tronics  Engineers  (IEEE)  has  adopted 
this  approach  in  their  Guide  For  The 
Use  Standard  Dictionary  of  Measures 
to  Produce  Reliable  Software. 

The  software  requirements  process 
has  improved  through  use  of  Ada, 
DOD-STDs  2167A  and  2168,  DOD 
5000.3-M-3,  and  commercial  and 
professional  society  standardization 
efforts.  These  provide  mechanisms 
for  defining  quantitative  software 
characeristics/ thresholds  for  incor¬ 
poration  into  system-level 
characteristics/thresholds.  Proactive 
management  advocates  capitalize  on 
this  foundation  to  implement 
measurement  and  evaluation  techni¬ 
ques,  metrics  or  indicators,  to  meet 
management  requirements.  This 
enhances  the  ability  to  define 
development  and  test  requirements, 
and  leads  to  quantitative  techniques 
for  measuring  success.  These  ini¬ 
tiatives  help  establish  quantifiable 
measures  that  permit  confidence 
building  and  traceability  across  the 
life  cycle. 


Current  practices  provide  a  signifi¬ 
cant  savings  over  the  traditional  soft¬ 
ware  acquisition  approach,  For  the 
100,000  LOC  program,  development 
costs  declined  from  traditional  ap¬ 
proach  cost  by  $3.4  million  to  $14.2 
million.  In  large  part,  savings  are  at¬ 
tributed  to  the  33  percent  reduction 
in  error  correction  cost  to  $2.7 
million  and  the  129  percent  improve¬ 
ment  in  error  prevention  savings  to 
$0.81  million.  From  a  life-cycle 
perspective,  total  cost  directly 
associated  with  error  correction  has 
been  reduced  by  38  percent  to  $4.8 
million.  (Table  3.) 

Projected 

Approach 

(SEI  Process  Levels  4-5) 

A  Level  4  (managed)  process  is 
understood,  quantified,  measured, 
and  well  controlled.  The  organization 
bases  its  operating  decisions  on  quan¬ 
titative  process  data;  i.e.,  analysis 
and  use  of  software  measurement 
data  gathered  during  software 
engineering  reviews  and  tests.  Tools 
are  used  to  control  and  manage 
development,  evaluation  and  test 
processes,  and  support  data  gather¬ 
ing  and  analysis.  The  organization  is 
learning  to  project  expected  errors 
and  applying  software  engineering 
discipline  (using  applied  math¬ 
ematics,  including  statistical  analysis) 
to  detect,  prevent  and  reduce  them. 


Level  5  (optimized)  organizations 
have  a  high  degree  of  process  control, 
and  a  major  focus  on  improving  and 
optimizing  operations.  This  includes 
more  sophisticated  analyses  of  the 
process'  error  and  cost  data  and  in¬ 
troduction  of  comprehensive  error 
cause  analysis  and  prevention 
studies.  Process  data  are  used 
iteratively  to  improve  the  process  and 
achieve  optimum  performance. 

This  approach  builds  on  current 
initiatives  and  application  maturity 
associated  with  their  use.  For  applica¬ 
tion  software  development,  measure¬ 
ment,  test  and  analysis,  it  capitalizes 
on  institutionalized  use  of  true  soft¬ 
ware  engineering  discipline,  effective 
software  engineering  environments, 
and  automated  tool  sets.  Through 
synergistic  effects  of  current  ini¬ 
tiatives,  it  is  possible  to  significantly 
improve  reliability  of  software  inten¬ 
sive  defense  systems,  while  reducing 
the  amount  (cost)  of  testing  and  im¬ 
proving  test  efficiency.  This  is 
achieved  by  effectively  applying 
TQM  concepts  to  defined,  measured 
and  understood  software  develop¬ 
ment,  test,  and  evaluation  processes. 

The  projected  approach  requires 
three  basic  elements,  discipline  and 
knowledge  of  the  process  and  pro¬ 
ducts,  requirements  definition  and 
understanding,  and  attributes  that 
can  be  measured  throughout  the 
system's  life  cycle  to  verify  require¬ 
ment  satisfaction. 
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Error  introduction's  primary 
source  during  the  development  pro¬ 
cess  is  the  requirements  phase  (Table 
1).  Among  the  dominant  causes  for 
high-error  insertion  are  incomplete, 
or  misunderstood,  requirements 
(especially  derived  requirement  for 
the  system's  software  components) 
and  improper  implementation  of  re¬ 
quirements;  i.e.,  requirements  and 
design  errors.  Requirements  errors 
are  reduced  through  a  requirements 
analysis  process  that  combines 
engineering  discipline,  human  ver- 
fication  and  statistical  evaluation 
(e.g.,  requirements  definition,  stabil¬ 
ity  and  completeness)  to  refine/define 
system  requirements,  including  de¬ 
rived  software  requirements,  to  a 
level  of  understanding  compatible 
with  the  software's  functional 
criticality. 

Process  evaluation  techniques 
(resource  utilization  rates,  test  and 
development  status,  and  cost/ 
schedule  deviations)  help  early  iden¬ 
tification  of  critical  software  design 
features  or  functions,  requiring  in¬ 
creased  management  and  engineering 
attention  to  prevent  error  introduc¬ 
tion  and/or  increased  analysis, 
including  test,  to  ensure  critical  error 
detection  and  correction. 

Product  evaluation  techniques  (ap¬ 
plied  mathematical  analysis)  and 
statistical  measures  (error  rates,  cor¬ 
rect  outputs  ratios,  requirements 
traceability,  test  coverage,  test  suffi¬ 
ciency,  and  documentation  indexes) 
are  used,  during  requirements 
analysis,  to  ensure  critical  error 
detection.  This  provides  management 
insight  into  the  degree  of  success 
associated  with  employed  error/ 
failure  prevention  techniques. 
Prevention  and  early  detection  sup¬ 
ports  identification  and  development 
of  required  test  scenarios  to  exercise 
software  in  ways  truly  representative 
of  the  user's  environment. 

A  hey  ingredient  in  obtaining  high 
reliability  software  is  discipline. 
Commitment  to  TQM  methods  to 
improve  proeess  and  products  is  but 
one  aspect  of  required  discipline. 
Another  aspect  is  effective  manage 
ment  control  of  requirements  (stated 
and  derived)  creep  during  develop 
ment.  Requirements  baselining  to 
obtain  a  known,  verified,  reliable 
software  product  is  essential  to  reduc¬ 


ing  risks.  This  is  the  essence  of  evolu¬ 
tionary  software  acquisition,  i.e., 
build  upon  existing  capabilities  to  add 
new  enhanced  capabilities. 

"Grand  Designs''  of  software¬ 
intensive  systems  is  a  major  factor  in 
the  failure  to  provide  quality 
software-intensive  systems  on  time, 
within  cost  and  schedule,  and  respon¬ 
sive  to  user  requirements.  Therefore, 
many  development  efforts  use 
"evolutionary”  methods  to  field 
systems,  by  building  a  “limited 
capability”  system,  with  planned 
growth  capabilities  and  related 
development  activities  to  mature  per¬ 
formance  over  time  and  capitalize  on 
customer  feedback.  The  primary 
focus  is  to  maintain  system  perfor¬ 
mance  integrity. 

With  well-defined  requirements, 
"stress"  test  scenarios  can  be  defined 
to  ensure  software  products  are  tested 
and  evaluated  in  a  user  representative 
environment.  This  increases  software 
reliability,  but  does  not  necessarily 
ensure  error-free  software.  Test 
discovers  the  presence,  not  the 
absence,  of  errors.  Undiscovered  er¬ 
rors  remaining  after  user  represen¬ 
tative  stress  testing  should  have  no 
serious  impact  on  overall  reliability. 
This  results  in  using  test  to  verify 
achievement  of  performance  levels, 
rather  than  the  traditional  use  of  test 
to  define  "acceptable"  performance 
levels. 

The  TQM  techniques,  defined  re¬ 
quirements  and  system  criticallity 
determine  software  components 
needing  engineering  and  management 
emphasis  throughout  the  develop¬ 
ment  process.  Statistical  and 
engineering  discipline  techniques 
(sampling  theory  and  mathematical 
proofs  of  correctness  for  software) 
reduce  software  development  process 
errors  from  current  industry  averages 
of  20-40  errors  per  thousand  LQC 
(KLOC)  to  less  than  5  errors  per 
KLOC.10  Using  TQM  techniques 
early  to  improve  requirements 
analysis,  definition,  and  implementa¬ 
tion  increases  up  front  costs, 
ty  pically  between  5  12  percent  ubo\c 
traditional  costs.  While  additional 
costs  can  be  considered  relatively 
small,  total  development  and  life 
cycle  cost  reductions  can  be 
substantial. 


Balanced  TQM  and  development 
methodologies  result  in  identifying 
specific  measures  of  merit,  attri¬ 
butes,  and  associated  performance 
thresholds  to  be  acheived  during 
development.  They  promote  and 
measure  software  reliability  and  per¬ 
formance  characteristics.  Effective 
and  productive  attributes  meet  three 
criteria:  be  consistent,  objective  and 
quantifiable  measures;  be  usable  for 
requirements  articulation  and  subse¬ 
quent  evaluation  of  actual  capailities; 
and  provide  traceability,  or  audit  of 
maturity,  across  the  development 
process.  Candidate  measures  are 
identified  in  DOD  5000.3-M-3, 
DOD-STDs  21 67 A  and  2168,  the 
various  Service  software  indicator 
pamphlets,  IEEE  Std  982-1989,  and 
RTCA/DO-178A. 

These  candidates  meet  the  prere¬ 
quisite  criteria.  They  are  not  com¬ 
plete,  nor  must  all  be  used.  To  be 
effective,  conscious-management 
decisions  must  identify,  implement 
and  use  only  measures  that  con¬ 
tribute  to  developing  a  software¬ 
intensive  defense  system  that  meets 
defined  performance  and  mission  re¬ 
quirements.  Blindly  requiring  all 
available  measures  uses  too  much 
data  collection  and  analysis 
resources,  w’ithout  a  commensurate 
return  on  investment  (ROD. 

The  projected  approach  provides  a 
significant  ROI  from  current  prac¬ 
tices.  Development  costs  declined  by 
S2.6  million  to  $11.7  million.  The 
decline  can  be  attributed  to  a  82  per¬ 
cent  error  correction  cost  reduction 
to  S0.48  million  and  a  124  percent 
error  prevention  increase  to  Si. 8 
million.  Total  life-cycle  error  correc¬ 
tion  costs  are  reduced  by  87  percent 
to  $0.63  million.  (Table  4.) 

Summary 

Software  development  is  human 
intensive,  thus  inherently  error 
prone.  Existence  of  software  errors 
does  not  a  priori  make  software 
unreliable.  Reliability  is  based  upon 
user  experienced  failures,  not  re¬ 
maining  software  faults.  Reliable 
software  needs  to  be  fault-tolerant, 
not  error  free.  More  than  half  of  IBM 
commercial  software  products  have 
mean-time  between  failure  rates 
greater  than  1500  years.11  Software¬ 
intensive  defense  systems  should  de- 
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TABLE  4.  PROJECTED  SOFTWARE  DEVELOPMENT  APPROACH 
COSTS 
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X 
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COCOMO  COST  ESTIMATE:  SIT, 664,694 


mand  at  least  the  same,  The  projected 
approach  supports  this  assertion. 

Synergistic  use  of  available 
development  and  evaluation  tech¬ 
niques  (engineering  discipline,  pro¬ 
cess  standardization,  requirements 
analysis,  measurement  methodolo¬ 
gies  and  TQM  approaches)  returns 
meaningful  balance  to  the  software 
equation.  This  balance  produces 
significant  cost  savings  for  software 
development  and  achieves  defense 
system  software  reliability  figures  at 
least  equal  to  those  obtained  with 
commercial  software  products. 

Achieving  balance  requires  the  ap¬ 
plication  of  management  commit¬ 
ment.  Any  additional  early  expen¬ 
ditures  will  be  more  than  offset  by: 
improved  requirements  definition 
and  implementation;  error  preven¬ 
tion  and  early  detection/correction; 
and  a  test  program  focused  on  veri¬ 
fying  requirements  achievement  in¬ 
stead  of  establishing  requirement 
specifications. 

Studies  by  Sunazuka  (et  al)  and 
Murine12 13  have  shown  the  follow¬ 
ing  benefits  are  achievable  through 
application  and  use  of  evaluation 
techniques,  in  essence  applying  TQM 
to  the  software  development  process, 
up  to  35  percent  development  cost 
reduction;  approximately  50  percent 
reductions  in  test  time  and  cost,  and 
50  percent  reduction  in  documenta¬ 


tion  to  define  specifications,  with  a 
corresponding  increase  in  specifica¬ 
tion  readability  and  understand- 
ability. 

In  light  of  ongoing  defense  expen¬ 
diture  reductions  and  the  increased 
competition  for  limited  resources, 
cost  alone  should  provide  sufficient 
motivation  for  discarding  the  tradi¬ 
tional  approach  entirely,  and  actively 
pursuing  transition  from  the  current 
to  the  projected  approach.  For  exam¬ 
ple,  if  an  organization  only  achieves 
the  50  percent  reduction  in  test  costs 
by  applying  TQM  to  the  develop¬ 
ment  process,  recognizing  that  test 
consumes  50  percent  of  the  total 
development  cost  (Figure  4),  that 
organization  has  a  25  percent  com¬ 
petitive  advantage  over  those  who 
fail  to  progress. 
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IN  MEMORIAM 


William  E.  Royers 
Adjunct  Professor  at  DSMC 


Mr.  William  E.  Rogers,  57,  direc¬ 
tor  of  logistics  at  Martin  Marietta 
Denver  Aerospace,  and  honorary 
professor  of  the  Defense  Systems 
Management  College  since  March 
1983,  suffered  a  massive  coronary 
February  23,  1991. 

Mr.  Rogers  was  a  1956  graduate  of 
Kansas  State  University  with  a  ma¬ 
jor  in  business  administration  and  a 
minor  in  electrical  engineering.  He 
obtained  a  FCC  first  class  radio¬ 
telephone  license  while  attending  col¬ 
lege,  and  afterward  was  an  officer  in 
the  U.S.  Army  Signal  Corps.  He 
joined  Martin  Marietta  in  1958  and 
worked  every  discipline  in  logistics. 
In  1978,  he  was  selected  integrated 
logistics  support  department 
manager. 


Mr.  Rogers  amassed  a  wealth  of 
logistics  knowledge  and  shared  these 
experiences  through  workshops— 
whether  they  be  international,  the 
Society  of  Logistics  Engineers,  or  in- 
plant  seminars  -and  the  DSMC 
Management  of  Life  Cycle  Cost 
Course  (MLCCC)  and  the  Manage¬ 
ment  of  Acquisition  I  ogistics  Course 
(MALC).  He  v  as  recognized  in  the 
logistics  community  as  an  innovator 
in  mathematical  modeling  techniques 
for  logistics  and  lite-cycle  cost 
analysis.  He  developed  many  original 
models  and  converted  numerous  ex¬ 
isting  models  to  run  on  program¬ 
mable  calculators  instead  of  the  more 
expensive  large-scale  computers.  Mr. 
Rogers  directed  the  first  symposium 
on  "Quality."  He  was  an  avid  sup¬ 


porter  of  the  College  Total  Quality 
Management  Course  and  enthusi¬ 
astically  promoted  an  understanding 
of  the  quality  improvement 
philosophy. 

Mr.  Rogers  was  a  senior  member 
of  the  Society  of  Logistics  Engineers, 
selected  by  the  Institute  of  Cost 
Analysis  as  a  Certified  Cost  Analyst 
and,  in  December  1990,  became  one 
of  the  first  DSMC  adjunct  professors. 

Mr.  Rogers  showed  integrity, 
dedication  to  truth,  and  a  search  for 
knowledge  by  demonstrating  and 
defining  instructions  as  a  professor 
and  teacher. 

He  is  survived  by  his  wife,  Arlene, 
and  daughter,  Susan,  of  Denver, 
Colorado. 
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INTERNATIONAL 

ARMAMENTS 

COLLABORATION 


hi  times  of  economic  and  political 
stability,  it  is  sufficient  to  "train" 
defense  and  other  officials  working  in 
the  international  arena  of  arms  col¬ 
laboration.  In  stable  times,  the  how¬ 
to-do  knowledge  can  be  imparted 
mechanistically. 

In  times  of  economic  and  political 
instability  or  permanent  dynamics, 
training  must  be  supplanted  by 
"education  "  about  the  driving  forces 
of  all  possible  future  partners  in  order 
(a)  to  conduct  international  col¬ 
laborative  defense  programs  without 
the  prior  experience  of  a  frozen 
paradigm,  and  (b)  to  develop  a  ra¬ 
tional  guess  about  possible  results, 
impacts  and  outcomes  of  negotiations 
in  the  international  arena. 

In  short,  in  the  future  we  will  need 
to  know  mote  about  oui  partneis. 
What  is  their  legal  lefeiencc  line,  their 
economic  system,  then  civilian  and 
defense  acquisition  system,  their 
cultural  preferences  and  so  forth? 
How  do  they  see  the  world? 

Hence,  education  "for  the  future " 
must  go  to  legal  economic  and  social 
piinciples,  to  the  cultural  drivers  and. 
possibly,  national  psychology.  This 
"general  knowledge'  will  enable 
future  defense  officials  to  develop 
their  own  strategy  for  international 
armaments  collaboration  and  to  live 
without  the  cookbook  knowledge  ac¬ 
quired  in  "training. " 

The  cookbook  foi  the  fulmc  can 
not  be  written. 

Ml.  Knatnuski  is  a  Pioflssoi  of 
Euqiueei  hip  A  lanapom  ut ,  Exult  tin  ami 
International  Department,  Defense 
Systems  Manqqement  Collate.  He  is  the 
Course  Dimtoi  fin  tin  Athamui  Into 
national  Mauqijciueiit  Workshop. 


n  June  1985,  the  Secretary  ol 
Defense  issued  a  memorandum 
to  the  Military  Departments,  the 
Joint  Chiefs  of  Staff,  Directors  of 
Defense  Agencies,  and  the  Under  and 
Assistant  Secretaries  of  Defense  plac 
ing  renewed  commitment  and  em¬ 
phasis  on  NATO  armaments  cooper¬ 
ation.1  The  Secretary  requested  that 
se\en  new  steps  be  taken,  the  seventh 
is  mv  topic  lor  this  article. 


This  step  requested  an  education 
program  ...  to  develop  and  maintain 
appreciation  for  the  significance  of 
the  individual  role  in  furthering  of 
collective  security  through  arma¬ 
ments  cooperation.  There  was  bad 
news  and  good  news. 


The  bad  news  was  that  the  educa 
tion  step  was  last  on  the  list. 
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To  avoid  confusion  about  various 
kinds  of  international  defense  pro¬ 
grams,  1  will  confine  my  remarks  to 
cooperative  programs.  These  are  pro¬ 
grams  where  the  United  States  and  at 
least  one  other  NATO  nation  (or 
other  designated  Ally)  make  an 
equitable  contribution  to  the  full  cost 
of  the  program  and  participate  in 
joint  management  of  the  program. 

The  projects  may  be  for  research 
and  development,  testing,  evalua¬ 
tion,  or  joint/concurrent  production 
(including  follow-on  support)  of 
defense  articles.2  These  exclude 
direct  commercial  sales  of  defense  ar¬ 
ticles  and  foreign  military  sales  under 
the  Security  Assistance  Program. 

Furthermore,  1  will  use  the  terms 
cooperation  and  collaboration 
interchangeably. 


The  good  news  was  that  we  finally 
made  the  cut. 

This  article  concerns  what  has  been 
clone  during  the  last  5  years,  what  we 
are  doing  now.  some  parallels  with 
international  education  in  the  private 
sector,  and  where  1  believe  we  should 
go  trom  here. 

1  should  point  out  at  this  time  that 
the  Deiense  S\  stems  Management 


Cm 


College  (DSMC),  Fort  Belvoir, 
Virginia,  is  the  only  educational  in¬ 
stitution  in  the  Department  ol  De- 
tense  ottering  courses  in  armaments 
cooperation.  These  are  the  Multina¬ 
tional  Program  Management  Course 
and  our  new  Advanced  International 
Management  Workshop.  I  will  elab¬ 
orate  more  about  these  armament 
coopeiation  courses  and  the  work 
shop  later  in  this  article. 


bThe  Past 

L  In  August  1087,  DSMC  completed 
■  a  survey  of  155  graduates  of  our 
W  Multinational  Program  Course.’ 
V  These  were  students  who  had 
graduated  from  the  course  from  one 
to  no  more  than  two  years  before 
conducting  the  survey.  The  makeup 
of  the  graduates  was  84  percent 
Department  of  Defense  (DOD) 
military  and  civilian,  8  percent,  in¬ 
dustry,  and  7  percent,  allied  nations. 
Results  of  that  survey  were  clear.  It 
indicated  that  DSMC  had  been 
responsive  to  the  needs  of  its 
customers,  but  due  to  changes  occur¬ 
ring  around  that  time,  especially  the 
Nunn4  ’  and  Quayle0  “  3  Amend¬ 
ments,  and  the  evolving  nature  of  in 
tcrnational  defense  programs.  man\ 
additions  and  improv  emails  could  be 
integrated  into  future  international 
activities  of  the  DSMC.  These  former 
students  telt  that  the  most  uselul 
aspect  ol  the  course  was  a  broaden¬ 
ing  in  perspective— imparting  an 
understanding  ol  both  the  variety  ol 
viewpoints  and  the  difficulty  ol  prob- 

EDITOR'S  NOTE:  This  is  Part  1  of 
III  of  a  papa.  The  Pioblan  of  Train¬ 
ing  and  Educating  Defense  Officials 
in  the  Aiena  of  International  Ai- 
niaments  Collaboration.  Part  ll  by 
Dr.  Fran:  A.P.  Frisch  and  Part  III  by 
Di.  Rolf  Claik,  both  of  DSMC.  a'tll 

appeal  in  subsequent  issues. 
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lems  in  the  international  arena.  This 
led  us  to  conclude  that  this  course 
was  an  excellent  baseline  from  which 
to  expand  and  incorporate  many  of 
the  suggestions  from  the  survey  and 
other  sources.  The  survey  report  also 
made  10  specific  recommendations, 
the  majority  of  which  DSMC  has 
been  able  to  implement. 

Two  years  later  we  initiated 
another  survey  of  armaments 
cooperation  educational  needs.9  This 
time  it  was  directed  to  program 
management  offices,  selected  DOD 
personnel,  and  attendees  at  a  seminar 
in  London,  conducted  by  the  Defense 
Systems  Management  College.  This 
survey  obtained  177  responses,  at  a 
remarkable  rate  of  more  than  60  per¬ 
cent.  The  results  indicated  a  very 
strong  need  for  education  or  training 
in  international  program  manage¬ 
ment.  Only  12  percent  of  the 
respondents  felt  that  existing  educa¬ 
tional  opportunities  were  adequate. 
Eight  specific  areas  of  knowledge  or 
understanding  were  identified  by 
more  than  30  percent  of  the  respon¬ 
dents  as  being  essential  to  their  jobs. 
Three  areas  stood  out  as  being  very 
necessary  to  all  respondents  as  well 
as  being  rated  as  essential  to  more 
than  40  percent  of  the  respondents 
with  international  involvement. 
These  were: 

—DOD  policy  related  to  technology 
transfer 

—DOD  policy  related  to  interna¬ 
tional  security 

—  International  Memoranda  of 
Understanding. 

The  topic  of  establishing  contrac¬ 
tual  arrangements  also  ranked  very 
high.  In  fact,  the  PMO  respondents 
with  international  involvement  rated 
this  area  highest.  Closely  following 
these  important  areas  came  four  ad¬ 
ditional  ones  which  were  considered 
necessary  to  all  respondents,  and 
rated  essential  by  at  least  30  percent 
of  those  with  international  involve¬ 
ment.  These  were  all  related  to  the 
DOD  policy  for: 

—Foreign  Military  Sales 
—License  Arrangements 
—Coproduction 
—Codevelopment. 


Conversely,  the  areas  of  knowl¬ 
edge  clearly  determined  to  be  least 
necessary  to  the  respondents  with  in¬ 
ternational  involvement  were  the 
following: 

—NATO  Organization  and  Func¬ 
tions 

—Acquisition  of  Foreign  Weapons 
Systems. 

I  will  save  my  remarks  on  how 
DOD  is  responding  to  these  findings 
to  when  I  get  to  the  present  and 
future  activities. 

I  would  now  like  to  move  on  to  the 
most  recent  examination  of  the  topic 
of  armaments  cooperation  education. 
This  examination  was  conducted  by 
a  committee  of  participants  at  the 
"Bonn  Seminar  on  Armaments 
Cooperation"  in  July  1989. 10  Educa¬ 
tional  issues  were  addressed  by  this 
committee.  Their  report  included  a 
recommendation  for  management 
resolve  to  educate  a  dedicated  corps 
of  international  armaments  coopera¬ 
tion  experts.  This  committee,  con¬ 
sisting  of  representatives  from  the 
United  Kingdom,  Germany,  France, 
Norway  and  the  United  States,  felt 
that  education  resources  were  inade¬ 
quate  or  non-existent  when  viewed  in 
relation  to  the  number  of  people 
needing  the  training,  like  offices  of 
defense  cooperation,  security 
assistance  offices,  research  and 
development  support  groups, 
ministry/department  of  defense 
staffs,  international  program  offices, 
industry  personnel,  educators  and  the 
public.  The  committee  concluded 
that  the  national  schools  should: 

—Evaluate  current  courses  taught  in 
the  national  schools  to  determine 
how  education  can  be  used  more  ef¬ 
fectively  to  achieve  better  armaments 
cooperation.  They  made  specific 
recommendations  about  resident  in¬ 
struction,  an  entry-level  course,  mid¬ 
level  courses,  and  a  senior-level  short 
course. 

—Develop  a  "how  to"  cookbook  on 
international  armaments  cooperation 
procedures,  processes,  organizations 
and  guidelines. 

—Develop  correspondence  courses. 

The  committee  further  concluded 
that: 

—Trained  and  experienced  arma¬ 
ments  cooperation  personnel  should 


be  identified  in  the  work  force,  and 
their  careers  managed  to  ensure 
repeated  international  assignments 
and  career  growth. 

—There  should  be  oversight  of  the 
education  system  by  high-level 
managers  responsible  for  interna¬ 
tional  armaments  cooperation. 

—Universities  should  be  encouraged 
to  include  armaments  cooperation 
issues,  policy  and  processes  in  their 
international  curriculum. 

—Professional  associations  should  be 
encouraged  to  sponsor  seminars  on 
international  armaments  cooperation 
issues. 

A  final  examination  of  the  question 
of  training  in  international  ar¬ 
maments  cooperation  came  during 
exhaustive  interviews  of  six  interna¬ 
tional  program  managers  as  part  of 
a  comprehensive  research  study  of  in¬ 
ternational  program  facilitators  of, 
and  barriers  against,  success.11  The 
following  question  was  asked. 
"Could  you  or  a  member  of  the  PMO 
staff  have  benefitted  from  training  in 
the  management  of  international  pro¬ 
grams;  and,  if  yes,  what  area 'topics 
would  have  been  useful?"  The  ques¬ 
tion  was  posed  to  the  program 
manager  for  the  NATO  Anti-Air 
Warfare  System,  the  Autonomous 
Precision  Guided  Munition 
(155MM),  the  Modular  Standoff 
Weapon,  the  Rolling  Airframe 
Missile,  the  Multiple  Launch  Rocket 
System  (Terminal  Guidance 
Warhead),  and  a  sixth  program 
which  provided  responses  on  the 
basis  of  non-attribution.  Five  of  the 
six  responded  "yes,"  whereas  the  one 
responding  negatively  said  that  "good 
people  with  a  good  work  ethic"  was 
more  important.  Of  course,  "good 
people  might  imply  experience 
and/or  training.  Four  of  the  five 
positive  respondents  identified  train¬ 
ing  in  the  area  of  allied  nation  pro¬ 
cesses,  such  as  decision-making, 
funding,  contracting,  tax  structure 
and  acquisition. 

As  one  can  readily  see,  much  has 
been  done  to  analyze  education  in  ar¬ 
maments  cooperation,  just  as  the 
Secretary  of  Defense  requested  5 
years  ago.  I  would  now  like  to  ad¬ 
dress  what  actually  has  been  ac¬ 
complished,  and  provide  some 
remarks  on  where  1  believe  we  should 
be  going. 
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The  Present 

As  mentioned,  the  Defense 
Systems  Management  College  is  the 
only  DOD  educational  institution 
having  a  program  for  international 
armaments  cooperation.  This  pro¬ 
gram  was  described  in  detail  in  an  ar¬ 
ticle  I  wrote  for  the  January  1989 
issue  of  Program  Manager 12  and  the 
Spring  1989  issue  of  the  DISAM 
Journals  The  following  is  a  brief 
description.  Our  educational  pro¬ 
gram  has  three  major  components: 

—The  Multinational  Program 
Management  Course  (MPMC) 

—The  Advanced  International 
Management  Workshop  (AIMW) 

—The  International  Defense  Educa¬ 
tional  Arrangement  (IDEA). 

The  first,  the  Multinational  Pro¬ 
gram  Management  Course,  is  the 
foundation  of  the  DSMC  interna¬ 
tional  armaments  cooperation  educa¬ 
tional  program.  It  is  the  baseline 
course  for  all  those  entering  this  field. 
Key  national,  DOD  and  Service 
policies  on  international  codevelop¬ 
ment,  coproduction  and  logistics  are 
explored.  We  offer  this  course  seven 
times  a  year. 

The  second,  the  Advanced  Interna¬ 
tional  Management  Workshop,  is  a 
focused  and  advanced  vyorkshop  on 
international  negotiation  and  acquisi¬ 
tion  management.  Participants  gain 
detailed  knowledge  of  and  practical 
skills  in: 

—International  Memoranda  of 
Understanding 

—  Preparing,  negotiating  and  staffing 
international  agreements 

—Specific  negotiation  issues 

—Factors  resulting  in  successful  inter¬ 
national  programs 

—Congressional  interaction  in 
cooperative  programs. 

This  workshop  has  received  con¬ 
siderable  interest  and  support  from 
the  Office  of  the  Secretary  of  Defense 
(OSD)  and  all  the  Services.  Nearly  a 
quarter  of  a  million  dollars  was  in¬ 
vested  by  OSD  and  the  Services  in 
workshop  development  and  mate¬ 
rials.  The  DSMC  spent  more  than  a 
year,  with  contractor  support,  in 
developing  the  workshop.  Our  first 
production  offering  was  June  18-22, 


1990,  and  recently  was  described  in 
National  Defense ,14  We  anticipate 
offering  three  workshops  a  year. 

The  third,  the  International 
Defense  Educational  Arrangement,  is 
a  grouping  of  national  defense  educa¬ 
tional  institutions  with  similar  goals 
whose  mission  is  to  improve  the 
economy,  efficiency,  and  effec¬ 
tiveness  of  international  training  and 
education  for  acquisition  manage¬ 
ment.  Current  members  are  the 
United  States  (represented  by 
DSMC),  the  United  Kingdom  (rep¬ 
resented  by  the  Royal  Military  Col¬ 
lege  of  Science),  and  the  Federal 
Republic  of  Germany  (represented  by 
the  Federal  Academy  of  Defense  Ad¬ 
ministration  and  Technology).  Addi¬ 
tional  national  defense  educational 
institutions  sharing  their  goals  are  en¬ 
couraged  to  join. 

I  would  like  to  mention  that  there 
are  several  other  government 
organizations  offering  short  courses 
that  could  be  beneficial  to  someone 
in  a  cooperative  defense  program. 
The  Defense  Institute  of  Security 
Assistance  Management  (DISAM)  of¬ 
fers  extensive  training  in  foreign 
military  sales  procedures  and  the 
Security  Assistance  Program.  The 
U.S.  Office  of  Personnel  Manage¬ 
ment  (OPM)  offers  courses  on  foreign 
policy,  national  security  policy  and 
technology  transfer,  as  well  as  occa¬ 
sional  seminars  on  trade  and  foreign- 
policy  issues.  Additional  specialized 
courses  exist,  like  the  NATO  Staff 
Officer  Orientation  Course  at  the  Na¬ 
tional  Defense  University  and  the 
Cross  Cultural  Communications 
Course  at  the  USAF  Special  Opera¬ 
tions  School. 

No  summary  of  training  oppor¬ 
tunities  in  international  armaments 
cooperation  would  be  complete 
without  mentioning  two  offered  in 
English  by  our  Allies.  The  first  is  the 
Management  of  International  Pro¬ 
jects  offered  by  the  Royal  Military 
College  of  Science  in  Shrivenham, 
United  Kingdom.  This  is  a  five-day 
course  for  senior  managers  with 
responsibilities  involving  interna¬ 
tional  programs  from  the  staff  of  the 
Ministries  of  Defense  of  NATO  and 
the  defense  industry.  Topics  covered 
are  concepts  of  collaboration, 
memoranda  of  understanding,  inter¬ 
national  management  structures,  in¬ 


dustrial  and  technical  issues,  and  con¬ 
tracts  and  finance.  It  is  offered  three 
times  each  year. 

The  second  training  opportunity 
offered  in  English  by  our  Allies  is  the 
EURO/NATO  Training  Weapons 
Systems  Management  Course  by  In- 
dustrieanlagen  -  Betriebsgellschaft 
mbH  (IABG),  a  company  working 
with  the  Germany  Ministry  of 
Defense,  located  in  Ottobrunn,  Ger¬ 
many  (a  suburb  of  Munich).  This  is 
a  two-week  course  for  middle-  and 
senior-management  personnel  in  the 
field  of  project  management  as  prac¬ 
ticed  in  the  development,  procure¬ 
ment  and  utilization  of  defense 
materiel.  Course  objectives  address 
the  management  of  NATO  ar¬ 
maments  programs,  international  ar¬ 
maments  cooperation,  life-cycle  tasks 
and  decisions,  and  exchange  of  ex¬ 
periences  among  NATO  partners.  It 
is  offered  only  once  each  year  in  the 
early  fall.  It  is  open  to  all  NATO  na¬ 
tions  on  a  quota  basis. 

This  completes  my  summary  of 
current  activities  in  armaments 
cooperation  education. 

Parallels  with 
Private  Sector 

I  would  like  to  draw  some  parallels 
between  our  efforts  at  the  Defense 
Systems  Management  College  in  in¬ 
ternational  training  for  defense  of¬ 
ficials  and  what  is  occurring  in  the 
private  sector.  A  recent  article  found 
in  the  Training  and  Development 
Journal 15  presents  a  statement  that 
"...most  business  leaders  say  that  in- 
tercultural  skills  training  is  essential, 
but  few  do  anything  about  it."  Citing 
a  survey  of  55  presidents  and 
chairpersons  of  Fortune  500  firms,  all 
agreed  that  "most  business  firms 
(domestic  as  well  as  multinational) 
will  be  directly  or  indirectly  affected 
by  economic  and  political  devel¬ 
opments  in  the  international  scene. 
Businessmen  will  therefore  need  to 
understand  and  anticipate  these  ef¬ 
forts."  However,  citing  another 
survey  of  multinational  U.S.  com¬ 
panies  only  12  percent  said  they  of¬ 
fered  seminars  and  workshops  on 
cross-cultural  aspects  of  doing 
business  in  foreign  countries. 

This  dismal  picture  was  reinforced 
b>  a  more  recent  article  in  the 
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Management  Development  Report.16 
Citing  an  executive  survey,  40  per¬ 
cent  of  respondents  said  that  interna¬ 
tional  business  is  currently  a  signifi¬ 
cant  part  of  their  overall  business, 
and  60  percent  reported  that  interna¬ 
tional  business  will  increase  during 
the  next  three  years.  This  article  fur¬ 
ther  stated  "numerous  studies  report 
that  70  percent  of  American  business 
people  who  are  sent  abroad  are  given 
no  advance  training  or  preparation." 
Academia  is  responding  to  the  inter¬ 
national  needs  of  business  either  by 
more  integration  of  international 
aspects  into  basic  classes  or  increas¬ 
ing  specifically  international  courses. 
The  situation  and  trends  in  academia 
are  well  summarized  in  a  recent  arti¬ 
cle  in  North  America  International 
Business 17 

Regrettably,  no  similar  set  of 
statistics  exists  for  international  ac¬ 
quisition  personnel  in  the  govern¬ 
ment.18  There  may  be  no  need  for 
such  statistics  if  one  believes  that 
defense  acquisition  personnel  respond 
to  government  policy,  rather  than 
market  forces.  Defense  policy  had 
been  determined  in  the  past  primar¬ 
ily  by  our  national  security  interests. 
Recent  trends  in  business  globaliza¬ 
tion  suggest  that  the  way  DOD  ap¬ 
proaches  acquisition  may  become 
more  influenced  by  economic  forces, 
both  domestic  and  international. 

The  Future 

I  would  like  to  make  a  few  remarks 
about  the  future.  These  remarks  are 
based  upon  the  surveys  and  studies 
I  previously  discussed,  as  well  as  my 
own  views. 

1  see  a  need  for  integrating  inter¬ 
national  aspects  into  all  basic 
domestic  acquisition  courses. 

1  see  a  clear  need  for  more,  mid¬ 
level  international  courses.  Specifi¬ 
cally,  three  opportunities  stand  out: 

—A  course  on  technology  transfer, 
defense  product  export  control  and 
international  security. 

—A  course  on  the  government 
aspects  of  international  defense 
business  management,  particularly 
focusing  on  contractual  aspects, 
financial  aspects,  licensing  arrange¬ 
ments  and  offset  agreements. 

—A  course  on  allied  nation  processes 
for  defense  acquisition,  decision¬ 


making,  contracting,  funding  and 
taxation. 

A  brief  executive-level  offering 
might  be  useful  for  senior  personnel 
who  have  recently  become  a  part  of 
the  international  process,  or  wish  to 
be  refreshed  on  current  topics. 

A  special  offering  emphasizing 
cooperative  opportunities  in  the 
Pacific  Rim  might  be  appropriate— 
especially  important  in  light  of  the 
turmoil  and  lack  of  clear  direction 
regarding  defense  policy  in  Europe. 

Finally,  I  would  like  to  see  a  com¬ 
puterized  management  information 
and  decision  support  system  on  inter¬ 
national  defense  agreements  be 
developed— one  that  could  be  ac¬ 
cessed  interactively  by  our  nego¬ 
tiators.  For  example,  while  we  were 
negotiating  the  memorandum  of 
understanding  for  the  Japanese 
fighter  support  experimental  (FSX),  it 
may  have  been  useful  to  have 
available  all  precedents  regarding 
technology  transfer  language  found 
in  other  approved  agreements. 
Ultimately,  the  ideal  would  be  a 
system  that  could  assess  the  impacts 
on  cost,  schedule,  performance  and 
supportability  of  an  international 
program  versus  a  national  program. 

As  you  are  now  aware,  we  have 
come  a  long  way  but  have  a  long  way 
to  go  in  international  armaments 
cooperation  training  and  education, 
as  you  will  see  in  the  two  future  ar¬ 
ticles  to  be  run  in  issues  of  Program 
Manager. 

Endnotes 

1.  Memorandum  from  the 

Secretary  of  Defense,  Subject:  "Em¬ 
phasis  on  NATO  Armaments 
Cooperation,"  June  6,  1985. 

2.  Memorandum  from  the 

Secretary  of  Defense,  Subject:  NATO 
Cooperative  Projects,  Jan.  28, 1986. 

3.  Multinational  Program  Manage¬ 
ment  Survey  Report,  Richard 
Kwatnoski,  DSMC  internal  docu¬ 
ment,  August  1987. 

4.  Public  Law  99-83,  Section  115, 
Amendment  to  the  Arms  Export 
Control  Act,  entitled:  "North  Atlan¬ 
tic  Treaty  Organization  Cooperative 
Projects,"  1985. 

5.  Ibid. 


6.  Public  Law  99-145,  Section  1102, 
FY 1986  DOD  Authorization  Act,  en¬ 
titled:  "Acquisition  of  Defense  Equip¬ 
ment  Under  North  Atlantic  Treaty 
Organization  Cooperative  Projects." 

7.  Public  Law  99-661,  Section  1103, 
FY  1987  Defense  Authorization  Act, 
entitled:  "Cooperative  Projects." 

8.  Ibid. 

9.  Multinational  Program  Manage¬ 
ment  Questionnaire  Report,  Michael 
G.  Krause,  DSMC  internal  docu¬ 
ment,  May  1989. 

10.  Bonn  Seminar  on  Armaments 
Cooperation,  proceedings,  cospon¬ 
sored  by  DSMC,  Royal  Military  Col¬ 
lege  of  Science,  and  the  Federal 
Academy  of  Defense  Administration 
and  Technology,  July  17-21,  1989. 

1 1 .  Interviews  conducted  by  Lt .  Col . 
C.  Michael  Farr,  USAF,  unpublished, 
circa  summer,  1989. 

12.  "Educational  Initiatives  in  Inter¬ 
national  Armaments  Cooperation," 
Program  Manager,  Richard 
Kwatnoski,  January-February  1989. 

13.  "Educational  Initiatives  in  Inter¬ 
national  Armaments  Cooperation  by 
the  Defense  Systems  Management 
College,"  The  DISAM  Journal  of  In¬ 
ternational  Security  Assistance 
Management,  Richard  Kwatnoski, 
Spring  1989. 

14.  "DSMC  Launches  New 
Workshop  in  International  Acquisi¬ 
tion  Management,"  National 
Defense,  April  1990. 

15.  "Preparing  the  New  Global 
Manager,"  Training  and  Develop¬ 
ment  Journal,  Madelyn  R.  Callahan, 
March  1989. 

16.  "Why  Aren't  American  Firms 
Training  for  Global  Participation?" 
Management  Development  Report, 
Marcia  Kirkpatrick,  editor,  Summer 
1990. 

17.  "The  Making  of  a  Global 
Manager,"  North  America  Interna¬ 
tional  Business,  Patricia  M.  Carey, 
June  1990. 

18.  The  term  "acquisition"  in  the 
defense  department  refers  to  the 
research,  development  and  procure¬ 
ment  of  defense  systems.  Acquisition 
personnel  are  therefore  analogous  to 
business  personnel  in  the  private 
sector. 
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DON’T  LET  THE 
SOFTWARE  DRAGON 
TAKE  A  BYTE 
OUT  OF  YOU! 

A  TTEND  DSMC'S 

INTRODUCTION  TO  SOFTWARE  MANAGEMENT 
ACQUISITION  COURSE 


-A  two-day  course  using  real- 
life  examples  of  software  man¬ 
agement  principles,  issues  and 
solutions. 

-Addresses  the  basic  theory 
and  practices  of  acquiring  mis¬ 
sion  critical  computer  re¬ 
sources. 

-Also  examines  the  software 
development  process,  test  and 
evaluation  ,  metrics  and  meas¬ 
urement  techniques,  post-de¬ 
ployment  support,  acquisition 
planning,  and  management 
techniques  from  government 
and  industry  points  of  view. 


-Consult  the  new  DSMC  1991  -Call  the  Registrar  (703)  664- 
Catalog  for  a  time  and  location  2152,  AV  354-2152-or  Jerry 


that  works  for  you. 

-For  military  officers  and  civil¬ 
ians  GS-9  and  above  in  the 
program  office  or  on  a  defense 
acquisition  staff,  or  equivalent 
industry  positions. 


Watson,  Course  Director  (703) 
664-4761,  AV  354-4761. 
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LOGISTICS  INTERFACE 
CONTROL  SYSTEM  (LICS) 


I'm//  I  Sktihix 
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'V  rmy  logistics  managers 

‘  now  have  another  tool  to 
assist  in  making  meaningful  con- 
tributuions  to  weapon  systems 
design.  It  is  the  Logistics  Interface 
Control  System  (LICS). 

The  LICS  is  a  systematic,  struc¬ 
tured  approach  enabling  logistics 
engineers  to  make  a  valuable  con¬ 
tribution  to  the  design  of  a  weapon 
system  throughout  the  Army  materiel 
acquisition  process  (MAP).  It  pro¬ 
motes  communication  between  logis¬ 
tics  and  system  design  engineers  early 
in  a  system's  acquisition  life,  serves 
as  a  catalyst  to  improve  the  quality 
of  the  concurrent  engineering  disci¬ 
plines,  reinforces  the  logistics  support 
analysis  (LSA)  process,  and  helps  to 
control  design  and  life-cycle  costs 
(LCC)  of  a  weapon  system. 

For  years  the  logistics  community 
has  been  promoting  the  concept  of 
supportability.  An  opportunity  to 
prove  this  concept  was  provided  to 
logistics  engineers  2  years  ago  on  a 
special  streamlined  weapon  system 
prototype. 

Alt-.  Skalny  is  a  logistics  management 
specialist,  Rescan!)  Development  mid 
Engineering  Center,  United  States 
Army  Tank-Automotive  Command 
( TACOAI ).  He  is  the  logistics  manager 
on  a  Defense  Admnccd  Resemch  Pivjects . 
Aqencx  < DAIU’A )  pwgram,  and  the  [ 
TACOM  IIS  and  AIAXPRIXT point-  i 
ofcontact  for  Linc-of-Sight  Antitank 
(I.OS A  T)  weapon  system. 

Mr.  Carey  is  a  principal  reseanh  scien¬ 
tist  with  Ilattelle  Memorial  Institute.  He 
is  the  senior  logistics  engineer  on  a  system 
engineering  technical  assistance  (SETA) 
contract  to  DA1U1  A.  Air.  Carey  is  a 
gmduate  of  the  Army  Command  and 
General  Staff  College. 


There  are  Challenges 

With  every  opportunity  there  are 
challenges,  and  this  weapon  system 
was  no  exception.  For  example,  the 
major  challenges  were:  No  predeces¬ 
sors;  it  was  in  the  proof-of-principle 
phase  with  no  integrated  logistics 
support  (ILS),  MANPRINT  or  relia¬ 
bility,  availability,  maintainability 
(RAM)  requirements  identified  in  the 
contract;  and,  it  involved  multiple 
contractors.  The  LICS  was  created  to 
meet  these  challenges  and  to  take  ad¬ 
vantage  of  this  opportunity. 


The  LICS  was  devised  to:  (1) 
generate  and  interact  between  the 
logistics  and  system  design  engineers, 
thereby  influencing  design  of  the 
weapon  system;  and  (2)  streamline 
the  contract  documentation  require¬ 
ments  as  prescribed  by  Department 
of  Defense  Directive  (DODD) 
5000.43,  Acquisition  Streamlining. 
With  this  in  mind,  the  following  LICS 
objectives  were  developed: 

-Identify  RAM,  MANPRINT,  sup- 
portability  and  accessibility 
issues/concerns 

—Identify  system  design  high-risk 
subsystems/components 


Ifelllf 
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TABLE  1.  ILS  ELEMENTS 

(1)  DESIGN  INFLUENCE 

(2)  MAINTENANCE  PLAN 

(3)  MANPOWER  AND  PERSONNEL 

(4)  SUPPLY  SUPPORT 

(5)  SUPPORT  EQUIPMENT  AND  TEST,  MEASUREMENTS,  AND 
DIAGNOSTIC  EQUIPMENT  (TMDE) 

(6)  TRAINING  AND  TRAINING  DEVICES 

(7)  TECHNICAL  DATA 

(8)  COMPUTER  RESOURCES  SUPPORT 

(9)  PACKAGING,  HANDLING,  AND  STORAGE 

(10)  TRANSPORTATION  AND  TRANSPORTABILITY 

(11)  FACILITIES 

(12)  STANDARDIZATION  AND  INTEROPERABILITY 
SOURCE;  AR  700-127 


—Establish  a  data  base  to  store, 
retrieve,  update  and  track  issues/ 
concerns 

—Provide  an  audit  trail  for  the 
ILS/MANPRINT/RAM  effort 
throughout  the  streamlined  acquisi¬ 
tion  process 

—Provide  the  project  manager/ 
deputy  project  manager  (PM/DPM) 
timely  logistics  information  when 
responding  to  senior  managers  and1 
congressional  inquiries 

—Assist  PM/DPM  in  making  deci¬ 
sions  relating  to  technical  perfor¬ 
mance,  schedule,  and  funding. 

Figure  1  illustrates  methodology  used 
to  generate  an  interaction  between  lo¬ 
gistics  and  system  design  engineers. 

First,  program  documents  like  the 
operational  and  organizational  plan, 
mission  needs  statement,  and  joint 
service  operational  requirement  are 
reviewed  to  determine  the  opera¬ 
tional  concept  and  to  ascertain 
whether  the  technology  for  the 
system  is  evolutionary  or  revolu¬ 
tionary.  Next,  the  contractor's 
technical  proposal  is  analyzed  to 
identify  the  different  types  of  equip¬ 
ment  and  subsystems  proposed  in  the 
design  of  the  weapon  system.  "Top 
level"  evaluation  of  the  proposed 
weapon  system  configuration 
(system/subsystems)  is  then  per¬ 
formed  by  a  small,  diverse  team  (3-5 
people)  of  experienced  logistics  and 
system  design  engineers. 

The  12  ILS  elements  shown  in 
Table  1,  along  with  RAM,  suppor- 
tability,  accessibility,  human  factors, 
safety  and  health  hazard  considera¬ 
tions,  are  used  as  a  guide  during 
evaluation  to  derive  specific 
ILS/MANPRINT/RAM  issues  for 
each  subsystem/component  compris¬ 
ing  the  weapon  system. 

The  issues  for  the  weapon  system 
are  developed  by: 

—Examining  the  program  documents 
to  determine  operational  mission  re¬ 
quirements  for  the  weapon  system 

—  Analyzing  the  contractor's  win¬ 
ning  technical  proposal  that  describes 
in  detail  (diagrams,  figures  and 
tables)  how  the  weapon  system  will 
be  designed  to  accomplish  the  opera¬ 
tional  mission  requirements. 

Some  typical  issues  might  be:  Are 
special  tools  and  test  equipment  re¬ 


quired  to  support  this  equipment  at 
each  maintenance  level?  Are  there 
any  special  or  unique  packaging, 
handling  and  storage  requirements? 
Are  special  support  (maintenance/ 
training)  facilities  required?  Is  the 
equipment  accessible  for  repair? 

The  initial  list  of  issues  is  then  pro¬ 
vided  to  the  prime  contractor's  ILS 
manager  in  both  paper  and  floppy- 
disk  media.  Shortly  thereafter,  a  joint 
government/contractor  working 
group  meeting  is  held.  Participants  in 
this  group  parallel  the  usual  make-up 
of  the  ILS  management  team 
(ILSMT).  Each  issue  derived  from  the 
"top-level"  evaluation  is  re¬ 
viewed/revised  and  quantitatively 


scored  and  ranked  by  the  working 
group  as  either  high,  medium  or  low- 
risk  and  as  either  high,  medium  or 
low  criticality.  The  total  risk  is  a  sim¬ 
ple  multiplicative  of  criticality  and 
risk  as  shown  in  Table  2. 

With  the  total  number  of  issues 
identified  for  each  criticality  and  risk 
category,  the  LICS  data  sheets  (Figure 
2)  are  completed  and  entered  in  the 
data  base  for  storage,  retrieval,  up¬ 
dating  and  tracking. 

A  Word  of  Caution 

As  you  can  see,  the  information  re¬ 
quired  on  the  LICS  data  sheet  is 
straightforward;  however,  a  word  of 
caution  is  in  order.  It  is  strongly 


TABLE  2.  CRITICALITY  AND  LIICH-RISK 
WEIGHTI NG  CR 1  TER  I A 

CRITICALITY  (O&O) 

(3)  HIGH  -  SIGNIFICANTLY  IMPACTS  OPERATIONAL  MISSION 

(2)  MODERATE  -  MODERATELY  IMPACTS  OPERATIONAL  MISSION 
(1)  LOW  -  MINIMAL  IMPACT  ON  OPERATIONAL  MISSION 

RISK  (RAM-S/MANPRINT  &  ACCESSIBILITY) 

(5)  HIGH  -  SIGNIFICANTLY  IMPACTS  WITH  NO  SOLUTION 
IDENTIFIED 

(3)  MEDIUM  -  SIGNIFICANT/MINOR  IMPACTS  WITH  SOLUTION 
OR  WORKAROUND  IDENTIFIED 

(1)  LOW  -  NO  IMPACT/NO  PROBLEM  IDENTIFIED 

TOTAL  RISK= (CRITICALITY  x  RISK) 
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FIGURE  1 .  LICS  METHODOLOGY 
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recommended  that  a  qualified 
engineer  provide  the  final  review  and 
actually  input  the  issues  into  the  data 
base.  A  qualified  engineer  should 
review  contractor  updates  before  in¬ 
formation  is  entered  in  the  data  base. 

Perhaps  the  key  to  the  LICS 
methodology  is  the  continued  coor¬ 
dination  of  issues  with  the  contrac¬ 
tor.  The  contractor's  ILS  manager  is 
tasked  to  take  the  LICS  issues  and 
redistribute  them  to  the  appropriate 
weapon  system  design  engineers  for 
resolution;  add  issues  recommended 
by  the  design  engineers;  provide  in 
process  reviews  (IPRs),  preliminary 
design  reviews  (PDRs)  and  critical 
design  reviews  during  1LSMT 
meetings.  The  status  of  the  high 
criticality/risk  items  are  briefed  to 
government  and  contractor  PMs  at 


physically  housed  at  the  Electronic 
Systems  Division,  Hanscom  AFB, 
Mass.  The  CGADS  uses  a  checklist 
method  of  asking  questions  to  suggest 
the  applicable  policies,  contract 
clauses,  tasks,  and  military  standards 
to  address  in  your  SOW.  The 
CGADS  is  a  good  development  aid 
for  providing  references,  but  it  does 
not  provide  good  examples  of  SOW 
tasking  statements.  Further  informa¬ 
tion  can  be  obtained  by  contacting 
Mr.  Fred  Santino  at  AV  478-7575. 

Other  automated  tools  include 
Docwriter  located  at  Space  Division, 
Los  Angeles  AFB,  Calif.,  and  a  Navy 
system  known  as  systematic  acquisi¬ 
tion  requirements  tailoring  and 
scheduling  (SMARTS).  Docwriter  is 
supposedly  reliable  for  those  access¬ 
ing  it  within  the  Los  Angeles  area,  but 
may  not  perform  as  admirably  when 
accessed  by  long-distance  modem. 
The  SMARTS  was  developed  to  tie 
together  modularized  acquisition 
documents,  like  the  SOW  and  CDRL, 
and  makes  use  of  extensive  cross- 
referencing.  The  SMARTS  point-of- 
contact  is  Mr.  Glen  Coleman  at  (703) 
602-7946. 

Recommendations 

Critical  questions  remain.  Is  the 
SOW  as  important  as  it  has  been 
made  out  to  be?  We  think  so. 

Are  current  sources  used  to 
educate  and  aid  in  SOW  develop- 


all  the  reviews.  Ultimately,  identified 
issues  are  incorporated  into  the 
system  specification. 

Using  LICS  allows  for  documenta¬ 
tion  requirements  to  be  streamlined. 
The  contractor's  explanation  on  how 
and  by  whom  the  issues  will  be  re¬ 
solved  provides  the  government  com¬ 
prehensive  information  on  the  con¬ 
tractor's  organizational  structure, 
logistics  and  system  design  engineer's 
responsibilities,  and  on  subcontrac¬ 
tors'  interfaces.  From  this  exchange 
of  information,  the  government  gains 
confidence  in  the  contractor's  capa¬ 
bility  to  resolve  the  LICS  issues.  Con¬ 
sequently,  logistics  requirements 
become  isolated  for  government  and 
contractor.  It  is  the  knowledge  that 
key  information  will  be  a  result  of  the 
LICS,  which  subsequently  allows  the 
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ment  sufficiently  detailed  and 
reasonably  available?  We  don't  think 
so. 

We  feel  our  few  recommendations 
are  essential. 

—Specific  courses  must  be  devel¬ 
oped  to  teach  SOW  preparation  to 
include  basic  technical  writing  skills; 
the  legal  implications  of  SOW  orga¬ 
nization  and  content;  and  the  in¬ 
tegrating  skills  needed  to  tie  SOW  re¬ 
quirements  to  other  parts  of  the 
contract. 

—Standardize  SOW  format  and 
SOW  preparation  policies.  There  is 
entirely  too  much  variety  and  too 
much  confusion  in  SOW  formats  as 
they  exist.  The  current  MIL-HDBK- 
245B,  with  minor  updating  and  im¬ 
provements,  could  serve  as  the  man¬ 
dated  baseline  for  SOW  development. 

—If  a  policy  is  not  instituted  to 
standardize  SOW  preparation,  then 
as  a  minimum,  the  Data  Require¬ 
ments  Review  Board  (DRRB)  should 
be  chartered  formally  to  perform  a 
final  review  of  the  SOW  and  CDRL 
for  consistency  and  applicability 
before  release  of  the  formal  solicita¬ 
tion.  We  believe  that,  collectively, 
people  in  the  government  do  not 
challenge  SOW  requirements  strongly 
enough.  The  program  managers  may 
be  held  ultimately  accountable  for 
SOW  content,  but  they  need  the 
advise  of  a  group  of  functional 


government  to  streamline  the  re¬ 
quired  contractual  documentation. 

The  LICS  is  an  example  of  concur¬ 
rent  engineering  in  action.  Experience 
with  the  special  streamlined  pro¬ 
totype  weapon  system  indicates  that 
LICS  is  influencing  the  design  and 
thereby  the  life-cycle  cost.  The  LICS 
provides  government  and  contractor 
ILS  managers  a  data  base  to  track 
issues  and  an  audit  trail  for  the 
ILS/MANPRINT/RAM  concerns 
throughout  the  materiel  acquisition 
process.  More  importantly,  by  im¬ 
plementing  LICS,  the  PMs/DPMs 
have  at  their  fingertips  an  automated 
near  real-time  management  tool  that 
gives  emerging  and  existing  design 
issues. 


experts  on  the  completeness  and  ac¬ 
curacy  of  the  SOW.  The  DRRB 
would  be  the  ideal  group  to  do  that. 
This  recommendation  is  not  our  orig¬ 
inal  idea.  To  the  Army's  credit,  they 
use  the  DRRB  in  this  fashion.  The 
MIL-HDBK-245B  encourages  using 
the  DRRB  for  reviewing  SOW  format 
and  content.  We  merely  are  adding 
our  support  to  the  recommendation. 


Summary 

As  this  and  our  previous  article 
have  stated,  we  have  many  problems 
associated  with  SOW  development. 
There  are  several  documents  avail¬ 
able  to  help  minimize  these  problems, 
like  MIL-STD-881  on  work  break¬ 
down  structure  and  MIL-HDBK-245B 
on  SOW  preparation.  There  are  soft¬ 
ware  tools  like  CGADS,  Docwriter 
and  SMARTS  to  assist  in  SOW  con¬ 
tent.  Unfortunately,  it  appears  we  are 
not  aware  they  exist  or  we  choose  not 
to  use  them. 

In  either  case,  the  result  has  been 
corroborated  by  our  program  man¬ 
ager  survey  that  our  SOWs,  in  gen¬ 
eral,  are  ineffective.  We  firmly 
believe  that  SOW  standardization  is 
a  must,  that  more  direct  emphasis 
needs  to  be  placed  on  an  educational 
program  for  SOW  development,  and 
that  a  final  structured  group  review 
of  the  SOW  is  needed  before  formal 
solicitation  release. 
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ACQUISITION  FOR  THE  FUTURE 


Imagination,  Innovation,  and  Implementation 

JUNE  4-6,1991 

SHERATON  NATIONAL  HOTEL 
COLUMBIA  PIKE  AND  WASHINGTON  BOULEVARD 
ARLINGTON,  VIRGINIA  22204 

The  1991  Acquisition  Research  Symposium  is  the  latest  in  a  series  of  conferences  that  began  in  1972.  This  year's 
Symposium  is  co-sponsored  by  the  Defense  Systems  Management  College  and  the  National  Contract  Management 
Association,  Washington,  DC  Chapter. 

FEATURED  SPEAKERS 

Dr.  Malcolm  R.  Currie,  Chairman,  CEO,  Hughes  Aircraft  Company  (KEYNOTE) 

John  Rittenhouse,  Sr.  Vice  President,  GE  Aerospace;  and  Chair, 

Defense  Science  Board  Acquisition  Streamlining  Task  Force 

Don  Fuqua,  President,  Aerospace  industries  Association  of  America,  Inc. 

PANEL  PRESENTATIONS 

SERVICE  ACQUISITION  EXECUTIVES 
MG  Lynn  H.  Stevens,  Commandant,  Defense  Systems  Management  College  (moderator) 

The  Hon.  Stephen  K.  Conver,  Assistant  Secretary  of  the  Army 
The  Hon.  John  J.  Welch,  Jr.,  Assistant  Secretary  of  the  Air  Force 
The  Hon.  Gerald  A.  Cann,  Assistant  Secretary  of  the  Navy 

INTERNATIONAL  ASPECTS  OF  ACQUISITION 

UPDATE  ON  CONGRESS 

CONCURRENT  SESSIONS 

Acquisition  research  papers  presented  during  thirty-two  concurrent  sessions  will  provide  a  dynamic  forum  for 
dialogue  with  key  professionals  working  on  vital  issues  facing  the  acquisition  community. 

EXHIBIT  HALL 

Numerous  exhibits  and  demonstrations  will  represent  some  of  the  latest  technological  and  educational  advances 
within  the  acquisition  community. 

REGISTRATION 

SYMPOSIUM  REGISTRATION.  Registration  fees  are  $195  (early  registration)  and  $245  (after  April  30, 1991)  and 
include  a  copy  of  the  Proceedings,  two  lunches,  coffee  breaks  and  reception  Tuesday  evening.  Attendance  will  be 
limited  to  350.  To  register,  send  check,  training  form,  or  purchase  order  to:  Acquisition  Research  Symposium,  c/o 
Dr.  Susan  Fieldman,  2710  Berryland  Dr.,  Oakton,  VA  22124,  or  call  301-925-9760,  or  703-620-9272  (evenings). 

HOTEL  RATES  AND  REGISTRATION.  Hotel  rates  are  $84.75  single,  $99.75  double,  plus  tax  (Government);  or 
$105  single,  $120  double,  plus  tax  (all  others).  For  reservations,  call  the  Sheraton  National  Hotel  at  703-521-1900 
or  1-800-468-9090  or  1-800-541-5500  (Virginia).  To  receive  these  rates,  state  that  you  are  attending  the  Acquisition 
Research  Symposium  and  make  reservations  no  later  than  May  20, 1991. 
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Success 


Viewpoints  on 

PROGRAM 

MANAGEMENT 

SUCCESS 


nn 


■I,  o  counteract  negative  pub- 
XL  licity  about  the  management 
of  defense  system  programs,  this 
paper  focuses  on  program  success. 
We  hope  that,  where  appropriate,  the 
factors  contributing  to  success  will  be 
adopted  by  current  and/or  future 
program  managers. 


Are  there  key  factors  leading  to 
successful  programs?  From  today's 
perspective,  it  appears  that  planning 
for  and  adapting  to  change,  and 
treating  a  program  as  a  business 
enterprise,  would  rank  high  on  any 
list.  Accommodating  changes  during 
defense  system  design,  development 
and  manufacture  requires  an  ag¬ 
gressive  leadership  team  that  remains 
in  charge  long  enough  to  lead  the 
program  through  critical  phases. 
From  the  outset,  government  and  in¬ 
dustry  managers  on  a  program  need 
an  effective  partnership. 


With  changes  on  the  European 
scene  and  scrutiny  on  the  defense 
budget,  there  will  be  fewer  new  pro¬ 
gram  starts  in  the  near  future  and  an 
increasing  need  for  technology  inser¬ 
tion  and  functional  enhancements  in 
existing  defense  systems  under 
development. 

There  is  general  agreement  by 
those  managing  defense  system  pro¬ 
grams  that  a  program  can  be  run  ef- 


Ms.  Lentz  is  Manager, ,  Systems 
Engineering  Pmess  Department,  Fedeml 
Sector  Division,  IBM,  Bcthesda,  Md. 
Mr.  Acker  is  Pivfessor  of  Management  at 
DSMC.  The y  are  active  on  the  DSMC 
Alumni  Association  Boaid  of  Directors. 
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fectively  when  there  is  teamwork  and 
trust  between  government  and  in¬ 
dustry.  Recent  legislation  to  further 
restrict  communications  between 
government  and  industry  during  the 
acquisition  phases  will  tend  to  hinder 
the  possibility  of  program  success.  It 
seems  important  to  review  techniques 
and  methods  used  on  well-run  pro¬ 
grams,  emphasizing  techniques 
leading  to  program  success. 

Success-Oriented 
Techniques  and  Methods 

Here  are  success-oriented  tech¬ 
niques  and  methods  most  good  in¬ 
dustry  program  managers  use. 

—They  act  with  authority  and  lead 
the  program  team,  but  delegate  some 
responsibilities  to  team  members, 
holding  them  accountable  for  results. 

—They  know  the  facts  or  obtain 
them  when  needed,  try  to  understand 
each  new  situation,  maintain  flexibil¬ 
ity  in  resolving  program  issues,  and 
learn  to  deal  effectively  with 
perceptions. 

—They  maintain  a  consensus  and 
support  members  of  the  program 
team,  avoiding  adversarial  relation¬ 
ships  if  possible. 

—They  maintain  a  strong  tie  and  a 
good  relationship  with  the  govern¬ 
ment  program  sponsor. 

—They  maximize  the  capability  of 
the  defense  system  while  striving  to 
decrease  complexity,  cost  and  time  to 
field. 

—They  strive  for  quality  in  the 
defense  system  and  management  of 
the  program. 


—They  recognize  the  need  for,  and 
support  field  testing  of  the  system 
under  development. 

The  government  program  manager 
maintains  a  good  relationship  with 
the  industry  program  management 
team  by: 


—Exercising  reasonable  program 
oversight 

—Conveying  trust  in  the  industry 
team  while  maintaining  a  close  rela¬ 
tionship  with  what  the  team  is  ac¬ 
complishing  at  the  program  level 

—  Developing  a  good  understanding 
of  the  contractor's  business  base  and 
approach  to  management 

—Conducting  periodic  reviews  of 
program  status 


—Responding  appropriately  to  re¬ 
quests  for  help,  advice  or  support 
from  the  industry  team 

—Taking  steps  necessary  to  ensure 
program  stability 

—Minimizing  paperwork  and 
reporting  requirements  to 
the  extent  possible. 

In  general,  a  good 
program  manager: 

—Fights  the  "right"  battles 

—Knows  and  accepts 
responsibility  for 
developing  people,  their 
loyalty  and  interests, 
and  a  team  spirit 

—Is  receptive  to  new 
ideas,  recogniz  ing 
productive  ideas  are 
apt  to  occur  to  the 
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person  looking  for  them 

— Has  ability  to  know  when  to 
depart  from  the  normal  and  when  to 
take  risks 

—Has  a  sense  of  humor  to  cushion 
bumps  along  the  road 

—Sees  the  good  in  subordinates  and 
tries  to  develop  their  good  qualities 

—Manages  his  time. 

Problems,  frustrations  and  success 
criteria  for  defense  programs  appear 
to  be  the  same  whether  a  program  in¬ 
volves  a  single  service,  joint  services 
or  an  international  team. 

During  the  years,  many  major  pro¬ 
grams  have  become  so  complex  that 
most  prime  contractors  cannot  meet 
all  requirements  without  the  support 
of  an  associate  contractor  or  contrac¬ 
tors,  many  subcontractors,  and  many 
suppliers  across  the  country/world. 
Increasing  regulations  and  paper¬ 
work,  and  the  need  for  increased 
automation  to  stay  competitive,  are 
driving  small  companies  and  sup¬ 
pliers  out  of  the  business.  This  is  in¬ 
creasing  the  dependence  of  American 


companies  on  foreign  suppliers.  This 
is  lengthening  the  lead  time  required 
for  production  and  increasing  the 
government's  cost  of  a  defense 
program. 

In  the  current  unstable  environ¬ 
ment,  where  decisions  by  the  Con¬ 
gress  and  Department  of  Defense 
management  are  almost  unpredict¬ 
able,  the  need  for  new  and  progres¬ 
sive  leadership  on  defense  programs 
is  essential.  The  acquisition  com¬ 
munity  needs  to  demonstrate  it  has 
the  leadership  capable  of  combating 
negative  trends  and  maintaining  the 
security  of  the  United  States  in  the 
face  of  declining  defense  budgets. 
Government/industry  program 
teams  need  to  approach  cutbacks  in 
a  positive  way  and  establish  a  "can 
do"  attitude,  while  achieving  the 
benefits  of  total  quality  management 
(TQM),  concurrent  (simultaneous) 
engineering,  and  computer-aided  ac¬ 
quisition  and  logistics  support 
(CALS). 

Principles  of  Good  Management 

We  believe  better  up-front  plan¬ 
ning,  concurrent  engineering,  and  in¬ 
tegrated  logistics  support  planning 
may  cost  more  in  program  initiation, 


design  and  development;  they  offer 
significant  payback  during  the  pro¬ 
duction  and  support  phases  of  a 
defense  program.  From  program 
start,  there  needs  to  be  an  ongoing 
dialogue  between  the  end-user  and 
design/implementation  contractor(s). 
There  needs  to  be  a  sane  budget  pro¬ 
cess  allowing  industry  to  plan  effec¬ 
tively  for  future  activities.  It  is  vital 
that  the  program  manager  have  an  ef¬ 
fective  engineering  function  respon¬ 
sible  for  achieving  a  technically 
"balanced"  and  economical  system 
design.  Such  engineering  responsibil¬ 
ity  will  demand  foresight  in  the 
creative  and  competitive  application 
of  technology  to  satisfy  defense  needs 
economically. 

Except  in  the  off-the-shelf  or  non¬ 
development  item  (NDI)  arena,  there 
are  requirements  to  be  shared  and 
technology  capabilities  and  limita¬ 
tions  to  be  considered.  Sometimes  the 
creative  talents  of  hundreds  of  peo¬ 
ple  need  to  be  channeled  to  produce 
a  prototype  or  engineering  develop¬ 
ment  model  of  a  defense  system  that 
can  be  produced,  fielded  and 
supported. 

Program  managers  applying  prin¬ 
ciples  of  good  management  reap  the 
benefits.  They  motivate  people  to 
produce— to  do  a  good  job.  Accord¬ 
ing  to  motivational  experts,  good 
program  managers  use  the  following 
approach: 
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—Recognition.  Make  sure  program 
team  members  feel  good  work  is  ap¬ 
preciated,  praised  and  awarded  when 
appropriate. 

—Self-expression.  Give  program 
team  members  the  right  to  com¬ 
municate  ideas,  suggestions,  opinions 
and  fears  without  concern  of  retribu¬ 
tion.  After  all,  we  live  in  a  democ¬ 
racy  and  no  member  of  the  program 
team  should  have  to  surrender  his 
heritage  when  serving  in  a  program 
office. 

—Self-respect.  Treat  program  team 
members  as  individuals  and  human 
beings— not  statistics. 

—Emotional  Security.  Make  pro¬ 
gram  team  members  feel  their  time 
and  efforts  will  be  rewarded  fairly. 

—Economic  Security.  Create  a  cli¬ 
mate  where  program  team  members 
trust  them  and  feel  their  jobs  con¬ 
tribute  to  a  worthwhile  goal. 

Successful  program  managers 
recognize  how  difficult  it  is  to  change 
themselves,  and  understand  they 
have  little  chance  of  changing  team 
members.  Further,  successful 
managers  feel  a  responsibility  for 
team  members. 

The  essence  of  program  manage¬ 
ment  success  is  to  set  a  long-range 
goal  and  relate  daily  work  to  it.  Some 
program  managers  have  only  a  vague 
idea  of  what  they  want  to  accomplish 
ultimately.  Even  when  they  do,  some 
PMs  do  not  know  how  to  translate 
their  desires  into  necessary  short- 
range  steps  to  ensure  reaching  the 
ultimate  goal. 


Dr.  William  Hunter, 
Lawrence  Lindsey 
and  Anthony  Batista 
discuss  program 
success  for  DSMC 
alumni. 


Point  and  Counterpoint 

At  the  DSMC  Alumni  Association 
Symposium  in  the  spring  of  1990  dur¬ 
ing  the  point-counterpoint  session, 
Dr.  William  N.  Hunter  asked  par¬ 
ticipants  Anthony  Batista,  consultant 
and  former  House  Armed  Services 
Committee  Director,  and  Lawrence 
B.  Lindsey,  Special  Assistant  for 
Policy  Development  to  the  U.S. 
President,  to  describe  program  suc¬ 
cess;  i.e.,  how  the  government  can 
provide  an  environment  where  con¬ 
tractors  successfully  adopt  creative 
and  innovative  ideas.  The  panel  in¬ 
dicated  there  needs  to  be  a  frame¬ 
work  of  realistic  goals  and  objectives 
on  each  defense  program.  Panel 
members  also  said  the  following. 


—The  formal  defense  system  plan¬ 
ning  process  should  be  flexible.  Pro¬ 
gress  is  often  slow  from  budget  crea¬ 
tion  to  budget  execution. 

—The  plan  on  each  program  must 
readily  accommodate  change. 

—More  attention  needs  to  be  focused 
on  manufacturing,  a  growing  seg¬ 
ment  of  our  economy. 

—National  laboratories  need  to  be 
structured  to  encourage  more  in¬ 
volvement  by  the  private  sector. 

—The  defense  acquisition  commu¬ 
nity  needs  to  focus  on  cost  reduction 
to  weather  problems  occurring  dur¬ 
ing  the  current  downturn. 

—Government  and  contractor  ac¬ 
quisition  executives  need  to  be  will¬ 
ing  and  able  to  work  as  partners  in 
dealing  with  the  Cotigress. 

—Defense  legislation  is  being  written 
on  the  floor  of  the  Congress  and 
should  be  written  in  committee. 

—When  a  program  manager  is  called 
to  Capitol  Hill  to  address  a  congres¬ 
sional  committee,  he  must  give  suf¬ 
ficient  thought  to  what  he  has  been 
doing  or  committee  members  will 
have  a  "field  day"  at  his  expense. 

—The  potential  of  the  peace  dividend 
should  be  viewed  with  caution.  The 
United  States  must  be  ready  to  make 
a  quick  recovery  if  the  peace  dividend 
suddenly  collapses. 
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Program  Management  Education 

The  need  for  adequate  preparation 
for  program  management  should  not 
be  treated  lightly  or  overlooked.  The 
Defense  Systems  Management  Col¬ 
lege  (DSMC)  is  providing  the 
necessary  background  and  direction 
to  prepare  military  service,  Office  of 
the  Secretary  of  Defense,  and  in¬ 
dustry  personnel  for  effective 
management  of  programs.  Demand 
for  graduates  of  the  DSMC  Program 
Management  Course  and  short 
courses  will  remain  strong  in  the 
foreseeable  future,  even  in  an  era  of 


1992.  This  will  help  satisfy  projected 
needs  of  organizations  sending  per¬ 
sonnel  to  the  course. 

—A  continuing  emphasis  on  acquisi¬ 
tion  management  research  and  the 
assembly  and  dissemination  of  infor¬ 
mation  concerning  policies,  methods 
and  practices  in  defense  acquisition 
management. 

—A  continuing  development  of  soft¬ 
ware  tools  to  be  used  as  decision  aids 
in  College  classrooms  and  provide 
management  aids  in  program 
management  offices  for  the  military 
services. 


—A  continuing  focus  on  total  quality 
management  because  it  presents  the 
challenge  and  opportunity  for  success 
in  managing  programs. 

Looking  outside  the  current  pro¬ 
gram  management  community,  there 
is  a  need  for  government  and  in¬ 
dustry  personnel  to  be  more  in¬ 
novative  by  interesting  students  at 
the  high-school  level  in  science, 
engineering  and  mathematics.  The 
future  is  in  the  hands  of  our  youth, 
but  we  can  help  now  to  ensure  our 
nation  will  survive  and  flourish  in  the 
future. 


declining  DOD  resources. 

Gregory  T.  Wierzbicki,  DSMC 
Deputy  Commandant  and  Provost, 
said  there  will  be  changes  and  contin¬ 
uing  emphasis  in  the  basic  program 
of  the  College  to  satisfy  its  chartered 
role.  Specifically,  there  will  be  the 
following. 

—A  return  to  two  Program  Manage¬ 
ment  Course  (PMC)  classes  per  year 
beginning  in  1991.  There  will  be  no 
overlap  in  these  classes  as  was  the 
case  recently.  This  will  provide  more 
opportunity  for  faculty  members  to 
keep  abreast  of  current  management 
practices  and  to  lead  development  of 
new  methods. 

—An  increase  from  630  PMC 
graduates  in  1990  to  840  graduates  by 


Joseph  Meredith, 
DSMC  Alumni 
Association  president, 
confers  with 
Gregory  Wierzbicki, 
DSMC  Pmvst,  at  the 
Spring  1990  Alumni 
Symposium. 


...there  will  be 
changes  and 
continuing 
emphasis  in  the 
basic  program  of 
the  College  to 
satisfy  its 
chartered  role. 

—Gregory  Wierzbicki 
DSMC  Provost 


Final  Thoughts 

We  would  be  wise  to  recognize  that 
the  art  of  leadership  is  to  retain  an 
adventurous  spirit  without  going 
overboard.  Successful  program 
managers  know  this  and  practice  it. 
Thomas  Drier  added  another  dimen¬ 
sion  by  saying,  "When  you  find  a 
man  who  knows  his  job  and  is  will¬ 
ing  to  take  responsibility,  keep  out  of 
his  way  and  don't  bother  him  with 
unnecessary  supervision." 

Surely  the  highest  reward  for  a 
program  manager's  labor  is  not  what 
he  "gets  for  it,"  but  what  he  "becomes 
by  it." 
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A  his  new  editon  edited  by 
Walter  Adams  distinguished 
university  professor  of  economics 
and  past  president  of  Michigan  State 
University,  recognizes  that  one  ma¬ 
jor  transformation  in  political  econ¬ 
omy  since  the  first  edition  (published 
in  1950)  is  renewed  awareness  that 
power  relationships  in  society  are  "a 
matter  of  profound  social  concern 
and  require  continuing  confrontation 
by  public  policy-makers." 

In  The  Federalist,  No.  51,  James 
Madison  said,  "A  dependence  on 
people  is.. .the  primary  control  on  the 
government;  but  experience  has 
taught  mankind  the  necessity  of  aux¬ 
iliary  precautions...."  These  auxiliary 
precautions  require  a  separation  of 
power  between  different  branches  of 
government,  and  dispersion  of  power 
among  the  citizenry.  Madison  wrote 
that  the  underlying  purpose  of  this 
arrangement  is  to  prevent  rulers  from 
oppressing  the  ruled;  and  one  seg¬ 
ment  of  society  from  oppressing 
another.  This  distrust  of  concentrated 
power  is  relevant  not  only  to  political 
but  to  economic  institutions.  When 
economic  power  exists,  it  eventually 
may  be  used  by  those  controlling  it 
for  whatever  ends  they  choose. 

There  is  a  debate  today  about  "the 
proper  role  of  government,  the  vir¬ 
tues  of  megamergers  and  corporate 
giantism,  the  challenge  of  interna¬ 
tional  competition,  and  the  need  to 
reindustrialize  America."  Therefore, 
the  timing  of  this  edition  is  excellent. 
It  offers  a  discussion  of  various  struc¬ 
tural  organizations,  behavioral  pat¬ 
terns  and  performance  records.  It 
places  emphasis  on  international 
comparisons  of  industries,  where 


they  are  relevant,  in  the  European 
economic  community  and  Japan. 
Because  each  industry  is  different,  the 
book  can  serve  as  a  "live”  laboratory 
for  clinical  examination,  comparative 
analysis,  and  the  evaluation  of  public 
policy  alternatives. 

The  book  concentrates  on  11  in¬ 
dustries,  including  petroleum,  steel, 
automobile,  computer,  and  weapons. 
The  book  contains  a  chapter  on  con¬ 
glomerates  and  a  chapter  on  public 
policy  in  a  free  enterprise  economy. 
Let’s  review  these  subjects  as  they  are 
covered  in  the  book. 

David  D.  Acker,  our  reviewer,  sems  in 
the  Research  Directorate  at  the  Defense 
Systems  Management  College. 


I  I  : 
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The  Petroleum  Industry.  This 
chapter  was  prepared  by  Stephen 
Martin,  professor  of  economics  at 
Michigan  State  University.  Martin 
examined  the  economic  and  political 
forces  that  have  determined  the  per¬ 
formance  of  the  world  oil  market  and 
the  U.S.  submarket.  He  indicated 
that  from  the  mid-1950s  through 
1973,  there  was  a  transition  from  a 
market  dominated  by  international 
major  producers  to  a  market 
dominated  by  the  governments  of  oil- 
producing  countries.  From  1973  to 
1986,  crude  oil  production  declined 
slightly  in  the  United  States  and  the 
trend  has  been  continuing.  Output 
from  Western  Europe  has  increased 
sharply  during  this  period;  however, 
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the  North  Sea  oilfields  probably  will 
peak  in  the  early  1900s  and  decline 
thereafter.  The  output  in  Latin 
America  has  risen  since  1973  and  the 
trend  probably  will  continue.  Crude 
oil  output  in  the  Third  World,  which 
includes  China  and  less-developed 
countries  in  Africa,  is  expected  to  in¬ 
crease.  Martin  claims  the  entry  of 
new  oil-producing  countries  is  under¬ 
cutting  the  power  of  Oil  Producing 
Export  Countries  (OPEC).  The 
OPECs  have  reacted  by  seeking 
secure  outlets  for  their  oil. 

The  Steel  Industry.  Walter  Adams, 
editor,  and  Hans  Mueller,  professor 
of  economics  and  finance  at  Middle 
Tennessee  State  University,  prepared 
this  chapter.  Until  the  1960s  "a  hand¬ 
ful  of  vertically  integrated  giants 
dominated  the  industry."  Then,  there 
was  an  invasion  by  domestic  and 
foreign  newcomers.  The  American 
steel  industries  pleaded  for  govern¬ 
ment  protection,  mostly  in  the  form 
of  trade  restraints.  By  the  1980s,  the 
steel  oligopoly  was  moribund.  There 
was  a  collection  of  helpless  giants 
begging  for  government  relief  from  a 
self-inflicted  injury.  Today,  the 
American  steel  market  is  composed 
of  about  10,000  distinct  iron  and  steel 
products.  These  products  are  dif¬ 
ferentiated  according  to  metallurgy, 
physical  properties,  and  surface  con¬ 
ditions.  The  term  market,  as  used  by 
the  authors,  connotes  the  interaction 
of  buyers  and  sellers  in  a  geographi¬ 
cal  trading  area.  In  the  United  States, 
the  structure  of  the  steel  market  is 
currently  an  oligopoly  dominated  by 
large  integrated  companies.  Adams 
and  Mueller  think  it  would  be  pru¬ 
dent  to  make  competition  "the 
lodestar  of  public  policy  regarding 
the  steel  industry." 

The  Automobile  Industry.  Walter 
Adams  and  James  W.  Brock,  pro¬ 
fessor  of  economics  at  Miami  Univer¬ 
sity  (Ohio),  believe  the  automobile 
industry  is  one  of  the  most  concen¬ 
trated  oligopolies  in  the  American 
economy.  They  divide  the  history  of 
this  industry  into  four  distinct  parts: 
(1)  the  era  of  independents;  (2)  the 
emergence  of  the  Ford  Motor  Com¬ 
pany  as  the  dominant  producer;  (3) 
the  shift  of  dominance  to  General 
Motors  and  progressive  industry  con¬ 
centration;  (4)  the  era  of  foreign  com¬ 
petition.  By  the  mid-1970s,  the  Big 


Three  (General  Motors,  Ford, 
Chrysler),  in  collaboration  with  the 
United  Auto  Workers,  made  repeated 
efforts  to  obtain  government  protec¬ 
tion  from  foreign  competitiors.  In  the 
1980s,  the  Big  Three  had  to  struggle 
to  advance,  both  by  product  innova¬ 
tion  and  by  new  production 
technology. 


The  Computer  Industry.  Gerald 
W.  Brock,  chief  of  the  Common  Car¬ 
rier  Bureau,  Federal  Communications 
Division,  explains  that  the  electronic 
digital  computer  was  "born  out  of  the 
critical  military  requirements  for 
computation  during  World  War  II 
and  the  early  cold  war."  The  heavy 
military  expenditures  on  computers 
by  the  United  States  made  the  early 
U.S.  industry  practically  synony¬ 
mous  with  the  worldwide  computer 
industry.  The  IBM,  although  not  the 
first  computer  company,  became  the 
world's  dominant  computer  com¬ 
pany  in  the  1950s  and  has  retained 
that  position.  According  to  Brock, 
the  highly  competitive  minicomputer 
and  microcomputer  market  seg¬ 
ments,  together  with  extensive  com¬ 
petition  from  Japanese  producers,  are 
now  reducing  IBM's  dominance  of 
the  worldwide  data  processing 
market. 


The  Weapons  Industry.  The  weap¬ 
ons  industry,  according  to  William  B. 
Barnett,  vice  president  of  Charles 
River  Associates,  and  Frederic  M. 
Scherer,  professor  of  economics  at 
Harvard  University,  is  one  of  the 
largest  and  most  fascinating  branches 
of  American  industry.  This  industry 
includes  aircraft,  guided  missiles, 
electronics,  computers,  communica¬ 
tion  systems,  shipbuilding,  and  ord¬ 
nance.  It  uses  many  of  our  nation's 
highly  skilled  scientific  and  technical 
human  resources  and  they  perform 
more  than  one-third  of  the  research 
and  development  undertaken  by  all 
U.S.  industries.  Further,  the  weapons 
industry  has  sustained  an  extraor¬ 
dinary  rapid  pace  of  technological 
advance  and  it  is  characterized  by 
unusually  large  uncertainties  con¬ 
cerning  product  characteristics  and 
costs.  Because  of  these  uncertainties 
and  the  large  size  of  the  individual 
defense  and  space  programs,  special 
institutions  have  been  created  to  shift 
financial  risks  from  the  producers  to 
the  government.  The  government,  in 
turn,  has  usurped  many  of  the 
decision-making  functions  tradi¬ 
tionally  exercised  by  sellers.  The 
authors  believe  that  few  things  are 
more  enduring  than  requests  for 
reform  of  the  system  by  which  the 
United  States  acquires  weapons.  In 
their  final  analysis,  Barnett  and 
Scherer  concluded  that  "the  most  im¬ 
portant  thing  that  can  be  done  to  im¬ 
prove  the  weapons  acquisition  pro¬ 
cess  is  to  bring  the  qualitative  arms 
race  under  control." 

Conglomerates:  A  "Nonindustry. " 
Willard  F.  Mueller,  professor  of 
economics  and  professor  in  the  Law 
School,  University  of  Wisconsin- 
Madison,  explains  that  the  large 
modern  corporation  typically  is  not 
confined  to  a  single  industry;  rather, 
it  embraces  many  lines  of  business, 
and  its  operations  often  extend  over 
much  of  the  world.  The  power  a  con¬ 
glomerate  has  within  a  particular  in¬ 
dustry  depends  on  its  market  posi¬ 
tion,  not  only  in  that  industry  but  in 
all  of  its  other  lines  of  business  at 
home  and  abroad.  The  trend  toward 
centralization  and  conglomerate 
bigness  is  becoming  greater  because 
corporate  decision-making  is  often 
centralized  by  numerous  joint  ven¬ 
tures  among  the  large  corporations. 

(Continued  on  page  47) 
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OFFSITE 


ORGANIZATIONAL 

INTEGRATION: 


ne  paradox  every  organiza¬ 
tion  faces  is  that  it  must  be 
divided  into  functional  areas,  dif¬ 
ferentiated,  to  deal  effectively  with  its 
environment.  Functional  areas  must 
be  integrated  if  an  organization  is  to 


Major  Wilson  is  a  Professor  in  the 
Policy  Organization  Management 
Department  at  the  Defense  Systems 
Management  College. 


meet  customer  expectations.  Organi¬ 
zations  operating  with  the  matrix 
structure,  like  program  management 
offices,  must  deal  continually  with 
this  paradox. 

Achieving  the  proper  integration 
level  is  critical.  In  this  article,  1 
outline  an  effective  model  for  a 
1-day,  offsite  to  allow  your  organiza¬ 
tion  to  determine  and  achieve  the  in¬ 
tegration  level  needed. 


A  skilled  consultant  managing  this 
process  is  usually  necessary.  It  is  im¬ 
portant  that  steps  outlined  be  fol¬ 
lowed  to  provide  optimal  results. 
First,  I  describe  the  process  and  then 
mention  critical  logistical  considera¬ 
tions  necessary  to  achieve  a  successful 
meeting.  At  first,  functional  PMO 
groups  will  work  together,  but 
separate  from  the  other  functional 
groups.  When  the  former  groups 


Our  top  priority  of  engineering  over  the  next  six  months  is. 


T)i«  data/help  we  need 
from  ottiar  group*  in  flit 
PMO  to  accomplish  this 
goal  are: 


This  is  critical 
to  our  success 


We  are  satisfied  with  the 
support  we  are  now  getting 


What  we  request 
from  the  others  is: 


Our  agreement  or 
action  plan  is: 


i 


*io 
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finish  individual  work,  they  interact 
with  each  of  the  organization's  other 
functional  groups  to  share  results. 

STEP  1 

Members  of  each  group  create  a  list 
of  goals  to  accomplish  in  the  next  6 
months. 

STEP  2 

Each  group  prioritizes  its  list  of 
goals. 

STEP  3 

Top  priority  will  be  written  in  a 
statement.  A  list  is  developed  of  in¬ 
puts,  coordination,  information,  etc., 
needed  from  the  other  functional 
areas  to  accomplish  this  priority  goal. 
A  list  is  developed  for  each  of  the 
other  functional  groups,  including  the 
PM  as  a  separate  "group," 

STEP  4 

Each  group  prioritizes  its  lists  of  in¬ 
puts,  coordination,  etc. 

What  has  been  created  to  this  point 
(see  illustration)  are  prioritized  data 
which  must  cross  boundaries  of  func¬ 
tional  groups  if  they  are  to  ac¬ 
complish  listed  goals, 

STEP  5 

Functional  groups  apply  the 
following  criteria  to  each  list  of  its 
data  for  each  other  functional  area. 

—Is  this  critical  to  your  team's 
effectiveness? 

—Are  you  satisfied  with  the  existing 
level  of  support? 

—What  request  do  you  have  for 
other  groups? 

—What  agreements  will  you  make 
with  other  groups  to  obtain  needed 
data? 

Each  functional  group  will  have 
developed  a  matrix  similar  to  Figure 
1. 

STEP  6 

Negotiate  agreements  with  each  of 
the  other  groups  to  obtain  the 
cooperation  needed  to  accomplish 
this  specific  objective,  the  group's  top 
priority.  This  is  accomplished  in  a 
round-robin  manner,  functional 
groups  paired.  An  alternative  is  for 
groups  to  gather  together,  one  at  a 
time,  and  for  the  entire  organization 
to  be  briefed  on  the  output  of  each 
group,  one  at  a  time.  This  ac¬ 
complishes  a  briefing  for  the  entire 
organization,  shows  amount  of  in¬ 


tegration  needed,  brings  all  person¬ 
nel  up-to-date  on  major  goals  of  all 
the  functional  areas,  and  gives  an  op¬ 
portunity  for  whole-group  interac¬ 
tion  regarding  goals. 

The  level  of  interdependence  re¬ 
quired  in  the  organization  is  indicated 
by  length  of  the  lists.  Longer  lists  in¬ 
dicate  a  need  for  a  high  level  of  in¬ 
terdependence  and,  therefore,  a  high 
level  of  integration  among  functional 
groups. 

This  design  has  at  least  three  sub¬ 
tle  aspects  which  participants  and 
consultants  need  to  know.  First,  the 
design  will  produce  a  lot  of  data.  Lists 
generated  by  each  functional  group 
will  be  long.  To  capture  this  data  ef¬ 
fectively  matrixes  should  be  prepared 
ahead  of  time  for  each  functional 
group.  Groups  should  not  use  ab¬ 
breviations  or  cryptic  language.  Out¬ 
siders  should  be  able  to  understand 
all  information. 

Second,  administrative  support  is 
needed.  Functional  groups  will  be 
busy  and  will  not  have  time  to 
transfer  data  to  a  medium  to  take 
back  to  the  office;  therefore,  take  per¬ 
sonnel  to  record  results  and  who  can 
be  utilized. 

Third,  offsite  meeting  facilities  are 
important.  This  model  works  best 
when  each  functional  group  has  a 
separate  room  and  the  walls  of  that 
room  can  be  covered  with  paper  to 
make  a  large  writing/working  area. 

In  1  day,  functional  groups  will  be 
able  to  negotiate  only  the  top  1-2 
goals. 

The  design  presented  herein  should 
allow  a  program  manager  to  deter¬ 
mine  the  level  of  integration 
necessary  among  PMO  functional 
groups.  Additional  benefits  might  be 
effective  teambuilding  such  as  in¬ 
cluding  new  members,  and  bringing 
other  members  up-to-date  on 
organizational  efforts. 

If  you  are  interested  in  discussing 
applicability  of  this  design,  please 
contact  me:  Major  Jim  Wilson, 
Defense  Systems  Management  Col¬ 
lege,  SE-P,  Fort  Belvoir,  VA 
22060-5426;  Commercial  telephone 
(703)664-3990,  or  Autovon  (354)3990. 


BOOK  REVIEW 

(Continued  front  page  45) 

The  author  believes  there  is  evidence 
that  vast  conglomerate  mergers  have 
increasingly  centralized  the  economy 
and  transformed  our  economic- 
political  order.  Proposals  to  restrain 
conglomerate  mergers,  according  to 
Mueller,  have  received  scant  support 
in  recent  years. 

Public  Policy  in  a  Free  Enterprise 
Economy.  Walter  Adams  identifies 
objections  to  monopoly  and  trade 
restraints:  (1)  monopoly  affords  lit¬ 
tle  consumer  protection  against  exor¬ 
bitant  prices;  (2)  monopoly  causes  a 
restriction  of  economic  opportunity 
and  a  misallocation  of  productive 
resources;  (3)  monopoly  often  re¬ 
strains  technological  advances  and, 
thus,  impedes  economic  progress;  (4) 
monopoly  tends  to  impede  the  effec¬ 
tiveness  of  stabilization  measures  and 
to  distort  their  structural  impact  on 
economy;  (5)  monopoly  threatens 
not  only  the  existence  of  a  free 
economy,  but  the  chances  of  survival 
of  free  political  institutions.  Adams 
says  the  Sherman  Act  of  1890  sought 
to  preserve  competitive  free  enter¬ 
prise  by  imposing  legal  prohibitions 
on  monopoly  and  free -restraint  of 
trade.  It  was  directed  against  existing 
monopolies  and  existing  trade  re¬ 
straints.  Enforcement  authorities 
were  not  able  to  cope  with  practices 
used  to  effectuate  unlawful  results 
and  they  could  not  attack  the  growth 
of  monopoly.  Adams  believes  that 
industrial  giantism  cannot  be  ignored 
because  "it  breeds  an  arrogance  of 
power  and  tends  to  divert  entrepre¬ 
neurship  from  risk-taking,  invest¬ 
ment,  research  and  development, 
productivity  enhancement  and  mar¬ 
ket  expansion  into  efforts  to  manip¬ 
ulate  the  state  for  protectionist  ends.'' 
Thomas  Jefferson  and  our  founding 
fathers  believed  that  "it  is  not  by  the 
consolidation  of  powers,  but  by  their 
distribution,  that  good  government  is 
affected."  This  proposition  is 
applicable  to  the  organizational  struc¬ 
ture  of  economic  and  political 
institutions. 

The  book  is  well  written  and 
thought-provoking.  Data  appear  to 
be  carefully  researched  and  findings 
will  be  of  special  interest  to  economic 
and  business-minded  students. 
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CAS  410 


GENERAL  & 
ADMINISTRATIVE 

Jjjmr  Bates  Do  Not  Mxevn  Lower  Costs 


nip 

iij  here  seems  to  be  renewed  ef- 
-  —  fort  in  obtaining  lower  rates 
for  contracts.  There  is  a  misconcep¬ 
tion  that  a  lower  rate  will  result  in 
lower  total  contract  costs.  There  are 
instances  where  a  lower  rate  can 
result  in  an  increased  allocation  of 
cost  to  a  contract,  as  I  will  show  in 
this  article. 

Focusing  on  the  rate  causes  one's 
attention  to  be  diverted  from  the 
elements  (pool  and  base)  causing  the 
rate  to  change.  The  easiest,  but  not 
necessarily  the  appropriate,  way  to 
lower  a  rate  is  to  reclassify  a  cost  in 
the  pool  so  that  it  is  pulled  from  the 
pool  and  placed  in  the  base.  Exhibit 
1  is  an  example  of 


/  fiii'i'i  I  A .  S o/irn'wr 


will  "purify"  the  general  and  ad¬ 
ministrative  (G&A)  expense  pool, 
causing  it  to  decrease.  Some,  if  not 
all,  of  these  costs  may  be  included  in 
the  G&A  allocation  base.  The 


decreased  pool  and  increased  base 
will  work  together  to  reduce  the 
G&A  rate,  thereby  creating  the  false 
impression  that  total  contract  costs 
also  will  be  lower. 


this  technique  ap¬ 
plied  to  manufacturing  overhead. 
The  rate  came  down  but  that  doesn't 
mean  any  less  cost  will  be  charged  to 
the  contract  because  the  $50  is  now 
a  direct  cost  rather  than  an  indirect 
allocation. 

Some  buying  offices  are  "en¬ 
couraging"  contractors  to  use  this 
methodology  because  their  rates  are 
"too  high."  If  the  contractor  follows 
through,  the  result  may  be  a  non- 
compliance  with  the  cost  accounting 
standards  (CAS).  However,  transfer¬ 
ring  a  cost  from  the  pool  to  the  base 
is  part  of  CAS  410:  Allocation  of 
Business  Unit  General  and  Ad¬ 
ministrative  Expenses  to  Final  Cost 
Objectives. 

The  operation  of  this  standard  may 
leave  a  big  misconception  in  its  wake. 
The  CAS  410  contains  features  that 
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EXHIBIT  1.  RECLASSIFY  AND  TRANSFER 


POOL  _  Manufacturing  Overhead 
BASE  Direct  Labor  Dollars 


$200 


$100 


=  200% 


Overhead 

Rate 


Reclassify  $50  of  Indirect  Labor 
as  Direct  Labor 


3 


$150 

$150 


=  $100% 


Overhead 

Rate 


The  intent  of  this  article  is  to  dispel 
the  myth  that  a  lower  rate  means 
lower  costs.  The  G&A  pool  and  the 
allocation  base  will  be  examined  from 
the  viewpoint  of  increasing  objectiv¬ 
ity  in  the  allocation  of  G&A  to  con¬ 
tracts.  The  means  to  achieve  greater 
objectivity  is  responsible  in  part  for 
creation  of  the  myth,  which  is 
perpetuated  by  a  misconception  of 
the  CAS  purpose. 


Purification  of  G&A: 

The  Myth  Begins 

Before  examining  provisions  of 
any  cost  accounting  standard,  the 
CAS  purpose  needs  clarification. 
Many  people  believe  standards  were 
written  to  reduce  the  cost  of.govern- 
ment  contracts.  Decreased  costs  may 
result  from  applying  the  standards 
but  this  was  not  the  focus  of  the  Cost 
Accounting  Standards  Board 
(CASB).  Its  main  concern  was  the 
equitable  allocation  of  costs  through 
consistent  application  of  standards 
designed  to  increase  objectivity.  One 
of  the  biggest  problem  areas  was 
allocation  of  G&A  to  contracts. 

Traditionally,  G&A  has  been 
viewed  as  a  period  cost  that  means 
it  does  not  become  part  of  the  cost 
and  a  product/contract.  However, 
government  contract  cost  accounting 
uses  full  absorption  costing,  which 
means  that  G&A  will  be  allocated  to 
government  contracts.  How  do  you 
accomplish  this  when  accounting 
literature  doesn't  address  it?  Thus, 
the  door  was  open  for  subjective, 
creative  and  arbitrary  allocation 


techniques  because  G&A,  by  its 
nature,  is  not  easily  allocated  since  it 
is  "related"  to  all  costs. 

The  title  "general  and  admin¬ 
istrative"  indicates  the  type  of  costs 
that  might  be  found  in  this  category. 
If  a  cost  was  not  related  to  some  other 
indirect  cost  pool  like  manufacturing 
overhead,  engineering  overhead, 
material  overhead,  etc.,  it  was 
thrown  into  the  G&A  pool.  Eventu¬ 
ally,  that  pool  became  a  collection  of 
costs  not  meriting  the  effort  to  deter¬ 
mine  individual  allocation  bases. 
Thus,  G&A  was  viewed  as  a  catchall 
of  general  costs. 

The  first  step  to  bring  order  out  of 
chaos  is  providing  a  definition  of  the 
costs  that  can  be  classified  ap¬ 
propriately  as  G&A.  The  CAS  410 
states  G&A  includes  expense  for  the 
general  management  and  adminis¬ 
tration  of  the  business  unit  as  a 
whole.  This  narrow  definition  is  the 
first  step  toward  "purifying"  the 
G&A  pool  and  also  is  the  beginning 
of  the  myth;  i.e.,  lower  rate  means 
lower  costs. 


Beware  of  Creative 
Allocations  That 
Can  Lead  to  False 
Redactions 


AIv.  Sotnwine  is  a  certified  cost  analyst, 
has  ken  an  auditor  with  the  Defense  Con¬ 
tract  Audit  Agency  and  is  a  member  of 
the  American  Society  of  Military 
Comptivllcis. 


Excluding  costs  from  the  G&A 
pool  does  not  mean  these  costs  are 
unallowable.  One  provision  of  CAS 
410  is  that  costs  are  not  properly 
classified  as  G&A  if  they  can  be 
allocated  by  a  base  better  than  cost 
input.  Examples  are  selling  expenses, 
personnel  department,  purchasing 
and  data  processing.  Each  can 
become  a  separate  indirect  cost  pool 
to  be  allocated  by  a  more  appropriate 
base  as  shown  in  Table  1. 
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TABLE  1 .  ILLUSTRATIVE  ALLOCATION  BASES 

COST _  ILLUSTRATIVE  ALLOCATION  BASES 

Selling  Expenses  Sales;  Cost  of  Sales 

Personnel  Dept  Headcount;  Payroll  Dollars 

Purchasing  Purchase  Order;  Value  of  Material 

Data  Processing  Machine  Time 


Pulling  these  costs  out  of  the  G&A 
pool  will  reduce  the  G&A  rate  but 
doesn't  mean  total  contract  costs  will 
be  lower.  These  costs  will  be 
allocated  to  contracts  by  a  more  ap¬ 
propriate  base  as  shown  in  Exhibit  2, 
Greater  objectivity  has  been  achieved 
where  little  or  none  existed  before  the 
standard. 

Reduction  of  the  G&A  pool  also 
was  aided  by  the  revised  Department 
of  Defense  (DOD)  weighted  guide¬ 
lines  for  determining  profit.  The 
G&A  is  no  longer  part  of  costs  used 
for  profit  calculation.  This  resulted  in 
contractors  reclassifying  previous 
G&A  costs  and  putting  them  in  other 
indirect  cost  pools  as  shown  in  Ex¬ 
hibit  3.  This  perpetuated  the  myth 
that  total  contract  costs  must  be 
decreasing  because  the  G&A  pool 
and  rate  are  decreasing. 

One  example  of  this  reclassification 
and  cost  transfer  involves  the  pur¬ 
chasing  department.  One  contractor 
said  that  purchasing  supported  only 
manufacturing  and  moved  the  cost  to 
the  manufacturing  overhead  pool.  In 
another  case,  a  contractor  pulled  the 
cost  of  the  accounts  payable  function 
out  of  G&A  and  transferred  it  to  the 


To  achieve  a  ‘true 


reduction  of 


contract  costs, 


at  lent  ion  must  he 


‘liver led  jront  the 
rule  to  coinootten! s 
oj  the  coir 


ceptable.  Two  popular  bases  were 
sales,  or  cost  of  sales,  and  direct 
labor.  Exhibit  4  shows  how  costs  can 
be  misallocated  by  using  a  cost-of- 
sales  base.  This  misallocation  is 
caused  by  holding  costs  in  the  work- 
in-process  account  for  fixed-price 
contracts.  Thus,  the  current-period 
G&A  will  be  allocated  to  cost  con¬ 
tracts.  When  costs  of  fixed  price 
contracts  are  released  from  the  Work 
in  Process  account  in  the  next  cost  ac¬ 
counting  period  they  will  pick  up 
their  share  of  that  period's  G&A.  The 
result  is  a  mismatching  of  G&A  to  the 
contracts  for  which  it  was  incurred. 

To  avoid  this  mismatching  pro¬ 
blem,  CAS  410  specified  the  ap¬ 
propriate  base  was  cost  input,  not 
cost  of  sales.  The  standard  provides 
three  forms  of  cost  input;  total  cost 
input,  value  added,  and  single  ele¬ 
ment.  The  appropriate  base  is  the  one 
best  representing  the  total  activity  of 
a  typical  cost-accounting  period. 
Selection  of  a  base  is  where  the  intent 
of  CAS  was  miscontrued. 

Those  thinking  CAS  was  intended 
to  result  in  the  least  cost  to  the 
government  would  select  the  base 
causing  the  lowest  allocation  of  G&A 
to  government  contracts.  Evidence  of 
this  can  be  found  in  the  General 
Dynamics  Convair  Division  case 
(ASBCA  22461).  In  his  decision,  the 
judge  said  that  inequity  does  not  arise 
because  the  system  caused  decreased 
costs  one  year  and  increased  costs  the 
next. 

Inequity  in  CAS  means  there  is 
disparity  between  cost  allocated  and 
benefit  received.  This  is  why  there  are 


material  overhead  pool  because  most 
of  the  effort  involved  processing  and 
paying  material  invoices. 

A  closer  examination  of  Exhibit  3 
shows  another  part  of  the  deception 
of  the  lower  rate— the  allocation  base 
increased.  Again,  one  provision  of 
CAS  410  causes  this.  Costs  excluded 
from  the  G&A  pool  as  a  result  of  one 
of  the  provisions  of  CAS  410  will  be 
part  of  the  cost  input  base  if  they  are 
not  allocated  using  the  same  base  as 
G&A. 

The  Myth  Is  Compounded 

Before  promulgation  of  CAS  410 
there  was  nothing  specific  concerning 
the  base  used  to  allocate  G&A.  Ac¬ 
cordingly,  almost  anything  was  ac- 


EXHttitr  2.  TV 


G&A  Pool 


ft'T  C&A 


Selling  Expenses 
Sales 

Personnel  Dept. 
Payroll  Dollars 
Purchasing 
Purchase  Orders 

Data  Processing 
Machine  Hours 


True  G&A 
Cost  Input 


Final 

Cost 

Objectives 

(Contracts) 
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EXHIBIT  3  INCREASED  OBJECTIVITY  VS. 

REDUCED  COSTS 


Material 

Before 

$100 

Labor 

100 

Mfg.  O/H 

100 

Engr.  O/H 

100 

Mat.  O/H 

100 

Q&A 

100 

IR&D 

100 

Selling  Expense 

0 

Total  Costs 

$700 

1195  -20% 

TCI  $500 

Reclassify/ 

Transfer  After 


$100 

100 

r+20 

120 

•+>10 

110 

+.10 

110 

•50- 

50 

100 

+•10 

10 

$700 

$50 

$550 

-11% 

TCI  -  Total  Cost  Input  -  All  costs  not  in  tha  G&A  pool  except  IR&D 
and  B&P. 


True  reductions  can 
be  obtained 
through  an 
analysis 

{cost  benefit,  value 


three  bases  available  under  CAS  410, 
each  eliminating  costs  that  may  be 
causing  a  disproportionate  allocation 
of  G&A. 

Total  cost  input  (TCI)  is  all  costs 
not  in  the  G&A  pool  except  indepen¬ 
dent  research  and  development 
(IR&D)  and  bid  and  proposal  (B&P) 
costs.  Value  added  (VA)  is  TCI  less 
material  and  subcontracting.  The 
single  element  base  with  the  widest 
use  is  direct  labor.  One  of  these  bases 
is  the  best  representation  of  total  ac¬ 
tivity  in  a  typical  cost  accounting 
period. 

By  definition,  the  TCI  and  VA 
bases  will  include  costs  eliminated 
from  the  G&A  expense  pool  except 
for  G&A  unallowable  costs.  Increas¬ 
ing  the  base  lowers  the  rate,  thereby 
compounding  the  myth  this  results  in 
lower  costs.  The  myth  is  com¬ 
pounded  ( urther  by  eliminating  costs 
from  the  bases. 

The  VA  and  direct  labor  bases 
eliminate  some  costs  from  the  base, 
thereby  causing  the  base  to  be  lower 
and  the  G&A  rate  to  be  higher.  Ex¬ 
hibit  5  demonstrates  the  fallacy  of  the 
myth,  "lower  rates  mean  lower 
costs,"  or  the  converse,  "higher  rates 
mean  higher  costs."  Look  at  Contract 
C.  Going  from  TCI  to  DL,  the  G&A 


rate  increased  but  costs  allocated  to 
C  decreased.  Although  the  myth  is 
supported  by  Contracts  A  and  B,  it 
doesn't  operate  in  all  cases.  Thus,  the 
myth  is  more  a  fallacy  than  it  is  a 
truism.  Total  G&A  didn't  change. 
The  allocation  was  rearranged. 

Caveat  Emptor 

The  buyer  must  be  aware  of  false 
decreases  achieved  by  way  of  creative 
allocation  techniques.  Lowering  the 
rate  doesn't  mean  an  automatic 


analysis,  etc.)  of 
the  individual 
costs  in  'the 
e.\pense  pool. 


EXUftUY  .p  C:rA  . 

1 1  .'IOC AVION; 

COST  INPUT 

VS.  ih  ts.e  i.U-  SA  LBS 

A 

B 

Total 

Beginning  Work  in  Process 

$  10M 

0 

$  10M 

Cost  Input  (M,  L,  O/H) 

$  70M 

$  30M 

$100M 

Ending  Work  in  Process 

$  60M 

0 

$  60M 

Cost  of  Sales* 

$  20M 

$  30M 

$  50M 

G&A  to  be  Allocated 

$  10M 

G&A  Rate 

Cost  Input 

10% 

Cost  of  Sales 

20% 

G&A  Allocation 

Cost  Input 

$  7M 

$3M 

$  10M 

Cost  of  Sales 

$  4M 

$  6M 

$  10M 

*  Assumes  all  goods  manufactured  are  sold. 
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EXHIBIT  5.  G&A  ALLOCATION 

Contract! _ 


Given: 

Total 

A 

B 

C 

Material 

$500 

$100 

$100 

$300 

Subcontracts 

400 

0 

200 

200 

Direct  Labor 

300 

120 

120 

60 

Overhead 

800 

280 

280 

240 

Total 

$2000 

$500 

$700 

$800 

G&A 

$200 

GFM* 

$200 

$200 

*  Government  Furnished  Material 

G&A  Allocation: 

A 

B 

C 

Total 

Tn  $200 

TCI  *2000 

10%  $50 

$70 

$80 

$200 

VA  - 
$1100 

18.2%  $73 

$73 

$54 

$200 

DL  5200  - 
$300 

66.7%  $80 

$80 

$40 

$200 

reduction  of  total  contract  costs. 
What  it  does  mean  is  that  there  will 
be  a  change  in  the  allocation  arrange¬ 
ment.  Looking  again  at  Exhibit  5  and 
going  from  VA  to  TCI,  the  rate  goes 
down  because  the  base  increased. 
This  resulted  in  a  shift  of  costs  from 
Contracts  A  and  B  to  C  (A  *  -23,  B 
=  -3,  C  —  +26).  This  shift  is  com¬ 
monly  made  from  fixed  price  con¬ 
tracts  to  cost  reimbursement 
contracts. 

To  achieve  a  true  reduction  of  con¬ 
tract  costs,  attention  must  be  diverted 
from  the  rate  to  components  of  the 
rate.  True  reductions  can  be  obtained 
through  an  analysis  (cost/benefit, 
value  analysis,  etc.)  of  the  individual 
costs  in  the  expense  pool.  If  a  true 
reduction  is  to  take  place,  a  cost  must 
be  eliminated  entirely  and  not  shifted 
to  another  pool. 

Another  alternative  to  lowering 
total  contract  costs  is  to  limit  the 
amount  of  G&A  the  government  is 
willing  to  pay,  but  this  has  its  pitfall. 
The  contractor  now  has  an  incentive 
to  reclassify  some  G&A  costs  and 
transfer  them  to  another  pool  to 
achieve  the  limit. 


Modem  Day 
“Forage” 
For  Iron  Horses 


In  the  midst  of  the  massive  deploy¬ 
ment  to  Saudi  Arabia,  in  October, 
the  Congress  and  the  Administration 
allowed  the  Defense  Production  Act 
to  expire. 

This  Act,  a  product  of  the  Korean 
Conflict,  provided  inter  alia  the 
authorities  for  priority  allocations  for 
the  military  of  materials  and  fuels 
should  such  be  required  in  national 
emergency  situations.  An  unknown 
bureaucrat  remembered  that  the  Civil 
War  "Feed  and  Forage  Act  of  1862" 
remained  on  the  books. 

Thus,  authority  for  priority  alloca¬ 
tion  of  fuel  for  military  needs  rests  on 
the  determination  that  petrofuels  are 
the  modern  forage  for  our  "iron 
horses." 


Experience  is  a  great  teacher,  but  it  can  be  an  expensive 
ana  dangerous  way  to  learn  the  program  management 
business.  The  best  part  of  the  Defense  Systems  Manage¬ 
ment  College  and  its  Program  Management  Course 
(PMC)  is  your  chance  to  learn  from  the  experiences  of 
others,  to  gain  the  technical  and  functional  skills  you 
need,  and  to  study  the  policies  that  govern  the  way  you 
do  business.  You’ll  hear  distinguished  guest  lecturers 
from  all  parts  of  the  defense  community.  Your  classmates 
will  include  industry  and  government  executives  as  well 
as  military  officers.  If  you  can’t  attend  our  premier 
20-week  PMC,  we  have  22  short  courses  you  might  try. 
Call  us  at  (703)  664-2152,  AV  354-2152  or  FAX  (703) 
355-7465  for  our  academic  calendar  and  College  catalog. 
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